[00:05.020 --> 00:10.480]  Hey, everyone. If you're anything like me, your missed calls list looks a lot like this.
[00:10.960 --> 00:17.420]  And I know I'm not unique. You know, the average person gets about 14 unwanted calls every month.
[00:17.420 --> 00:21.760]  And you might notice that some of these in my call list are flagged as spam, which is somewhat
[00:21.760 --> 00:27.800]  useful. But what if we could actually start to verify callers? What if we weren't just flagging
[00:27.800 --> 00:32.380]  things as spam and potentially harmful, but actually doing the opposite and saying, hey,
[00:32.380 --> 00:38.520]  you can trust this call? We already do this with websites. We already do this with emails.
[00:38.520 --> 00:45.220]  Why can't we do this with phone numbers? The good news is the short answer is that we can.
[00:45.260 --> 00:49.820]  And I'm going to be telling you about this TLS-like technology that's been developed to
[00:49.820 --> 00:55.760]  solve the call authentication problem. It's called Shake It and Stir, and we'll be diving into the
[00:55.760 --> 01:01.660]  history of why this is a problem, some definitions and technical details of the spec, how the U.S.
[01:01.660 --> 01:07.020]  is going to enforce implementation. Unfortunately, a lot of this is specific to North America right
[01:07.020 --> 01:11.780]  now. But we'll also be diving into the limitations of what this technology is,
[01:11.780 --> 01:16.840]  one of those obviously being that it's not applicable to the rest of the globe yet.
[01:17.500 --> 01:22.640]  So my name is Kelly Robinson. I have been working at Twilio for about three years. Twilio offers a
[01:22.640 --> 01:27.320]  lot of communication services, including a lot of stuff around telephony. I actually work on
[01:27.320 --> 01:31.400]  Twilio's account security products for things like phone verification. But this was just something
[01:31.400 --> 01:37.420]  that I got really interested in in terms of what the telephony security of actually authenticating
[01:37.420 --> 01:42.540]  call systems was. So we have a separate team that I'm not involved with at Twilio that is working
[01:42.540 --> 01:47.780]  on implementing some of this stuff, but this is just some of my own research into what this is,
[01:47.780 --> 01:53.080]  how it works, and hopefully I can share that with you in somewhat of an introduction to what
[01:53.080 --> 02:00.400]  Shake and Stir is. 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:13.340]  There was a monopoly of companies, and even as recent as 30 years ago, the network basically
[02:13.340 --> 02:19.460]  looked like this. It was private, it was closed, there was proprietary technology everywhere, there
[02:19.460 --> 02:23.400]  were just a couple of companies, and they all basically knew how to trust each other. They all
[02:23.400 --> 02:28.420]  knew who they were dealing with, and they all had direct lines of communication with one another.
[02:28.940 --> 02:33.700]  And if you compare that to today, there's literally thousands of companies. It's really easy
[02:33.700 --> 02:40.080]  to access this technology. There's more standard technology now built on top of IP, so you don't
[02:40.080 --> 02:45.360]  have to have this kind of proprietary technology and a lot of infrastructure to get started,
[02:45.360 --> 02:50.220]  and there's all these potential paths and routes for a call to take. And you can think of the
[02:50.220 --> 02:55.520]  difference in accessing the telephony network like you would in deploying a website today. So this is
[02:55.520 --> 03:00.380]  the difference between having your own on-prem hardware, your own servers that you're running,
[03:00.380 --> 03:05.840]  versus today you can use something like AWS to get up and running very quickly.
[03:07.280 --> 03:11.020]  And before we dive into this a little bit further, I do want to give a little bit more
[03:11.020 --> 03:16.260]  context on some telephony jargon. If you aren't familiar with telephony, I wasn't before I started
[03:16.260 --> 03:22.260]  working at a telephony company. And starting with the PSTN. So this is the analog and digital
[03:22.260 --> 03:28.120]  systems like cellular networks, undersea fiber optic cables, and copper telephone lines. And
[03:28.120 --> 03:32.900]  this is what allows people across the globe to complete voice calls. Something that you might
[03:32.900 --> 03:37.020]  have heard of before is VoIP, and this is the voice over internet protocol. This is what a lot
[03:37.020 --> 03:42.560]  of mobile infrastructure and businesses are actually using now. And so this is what people
[03:42.560 --> 03:47.780]  are moving towards. This is kind of the standard technology that people have more access to now,
[03:47.780 --> 03:55.860]  but it can also interact with the PSTN. And then finally SIP is a way to initiate IP phone calls
[03:55.860 --> 04:01.200]  and other communications. You can kind of think of it like an HTTP request for phone calls. It
[04:01.200 --> 04:06.640]  contains metadata and instructions about where a call is both coming from, who it's going to,
[04:06.640 --> 04:12.240]  and some other data about what the call should be. And the important thing to note here is that
[04:12.240 --> 04:19.220]  shaken and stir will only apply to SIP initiated phone calls. And so let's kind of talk about what
[04:19.220 --> 04:24.400]  the problem is here. And I specifically frame this as unwanted robocalls because not all robocalls
[04:24.400 --> 04:28.860]  are bad. So you can think of things like prescription pickup notifications, food delivery
[04:28.860 --> 04:34.220]  services, you know, things like the school has a snow delay type thing. There's reasons to
[04:34.220 --> 04:40.520]  automatically dial, but we do know that most of the robocalls that we get aren't that. They're
[04:40.520 --> 04:45.540]  spam and that's bad. And so we wanted to focus on the greater problem of the unwanted robocalls
[04:45.540 --> 04:50.600]  here. And the reason this is a problem, it's gotten super common in the last five to ten years
[04:50.600 --> 04:55.500]  for a few main reasons. First, there's a lot of cheap dialers now. It's really easy to do this
[04:55.500 --> 05:02.700]  automated dialing in an efficient way that actually makes spam and fraud more both efficient but also
[05:02.700 --> 05:08.200]  profitable. And second, there's over 4,000 service providers in the U.S. alone and that makes it
[05:08.200 --> 05:15.040]  easier to access and also gives you more access options to access the PSTN. And third,
[05:15.040 --> 05:21.040]  there's no validation or authentication on who is placing a call. So you can basically set the
[05:21.040 --> 05:25.920]  from number to whatever you want. And so there's an app that I downloaded at iOS that just lets you
[05:25.920 --> 05:30.220]  spoof phone numbers. And you don't really even have to know how SIP works. Like there's a way
[05:30.220 --> 05:36.260]  that you can do this with some SIP knowledge that's even more cheap. But there's like these
[05:36.260 --> 05:41.200]  consumer applications that you can download if you're an iOS or Android user that, you know,
[05:41.200 --> 05:45.040]  you don't have to have any technical know-how. And you can just have to believe me that this
[05:45.040 --> 05:52.660]  is a call I placed to myself from 867-5309. So you might be asking, like, why isn't this
[05:52.660 --> 05:57.840]  just illegal, right? And the main reason is that because there are some legitimate use cases for
[05:57.840 --> 06:03.080]  spoofing phone numbers. So nowadays the practice for companies like Uber or DoorDash or something
[06:03.080 --> 06:08.220]  like that, they'll proxy phone calls through a third number that connects individuals. So like
[06:08.220 --> 06:14.340]  when you call your Uber driver, when your DoorDash delivery person calls you, you're not getting a
[06:14.340 --> 06:19.080]  phone call from their number. You're getting a phone call from a third party, a number that's
[06:19.080 --> 06:24.400]  being proxied in between you. And that, you know, has privacy use cases and also some cost-saving
[06:24.400 --> 06:30.260]  measures. But it wasn't always like that, right? And so you also had enterprise systems or private
[06:30.260 --> 06:35.880]  branch exchanges that might be placing a call to a customer from an individual agent's line,
[06:35.880 --> 06:40.280]  but they want to display something like the toll-free callback number. And historically,
[06:40.280 --> 06:44.620]  those were just spoofed. You would say, hey, this isn't coming from me, Kelly. This is coming from
[06:44.620 --> 06:50.160]  my organization. And I want to make sure that you see this phone number in case you need to
[06:50.160 --> 06:55.380]  call that back. And these systems still exist. So we can't just outlaw this completely.
[06:56.280 --> 07:02.720]  In fact, the New York Times actually spoofed their from number until 2011, you know, and it was one
[07:02.720 --> 07:06.540]  of those things to help protect their sources if journalists were calling from their desk phones
[07:06.540 --> 07:11.240]  that didn't want to necessarily be calling from an individual journalist's phone. But they now
[07:11.240 --> 07:19.570]  actually will use a 212 number that you can call back. We did introduce some legislation to address
[07:19.570 --> 07:24.470]  this. The 2009 Truth and Caller ID Act was what did that. So again, this is only about 10 years
[07:24.470 --> 07:29.110]  old that we started to really think about this as a problem. But we can't completely ban call
[07:29.110 --> 07:33.690]  spoofing because of the legitimate ways that businesses are still using it. So legislation
[07:33.690 --> 07:39.490]  specifies that it is illegal to spoof numbers if there's that intent to defraud. But there's also
[07:39.490 --> 07:44.310]  this enforcement struggle with this. Because the network hops, it might take five or 10 service
[07:44.310 --> 07:49.750]  providers before you know who actually initiated the call. And they might or might not be able to
[07:49.750 --> 07:54.110]  tell you about the caller because they're placing calls on behalf of many, many customers.
[07:54.590 --> 07:58.810]  Tracking down a spammer takes a lot of time and effort and therefore money. And that makes
[07:58.810 --> 08:04.230]  enforcement of this really hard. So that brings us to the solution. That brings us to Shaken and
[08:04.230 --> 08:09.970]  Sturr and what we're here to do. 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:21.750]  Sturr, again, is secure telephony identity revisited. It does get worse. There's a
[08:21.750 --> 08:26.370]  proposal out there for Lemon Twist, but we're not even going to look at that because I think
[08:26.370 --> 08:32.190]  people are just getting a little too creative. But basically as the FCC describe it, what Shaken
[08:32.190 --> 08:37.590]  and Sturr does, calls would have their caller ID signed as legitimate by the originating carriers
[08:37.590 --> 08:43.710]  and then validated by the terminating carriers before reaching consumers. And so this is where
[08:43.710 --> 08:49.530]  it comes into that TLS-like authentication. You are signing calls as legitimate and then the
[08:49.530 --> 08:55.170]  terminating service provider would then display some information to the end user signifying that
[08:55.170 --> 09:00.910]  calls can be trusted and they were not spoofed. And we're not reinventing the wheel here. We're
[09:00.910 --> 09:05.250]  borrowing from other web authentication, things like public key infrastructure, certificates,
[09:05.250 --> 09:10.930]  JSON web tokens are all being used for this. And it's very similar to emails DKIM and DMARC,
[09:10.930 --> 09:17.150]  which basically authenticates the from sender in an email. And so a lot of the work that was done
[09:17.150 --> 09:22.150]  on Shaken and Sturr was done in conjunction with some of the authors from DKIM and DMARC
[09:22.150 --> 09:27.130]  as a way to set best practices for this type of communication.
[09:28.190 --> 09:33.330]  And this is a simplified view of the end-to-end system, what happens with the Shaken and Sturr
[09:33.330 --> 09:37.730]  signed calls. So the signing service includes some public key infrastructure key management
[09:37.730 --> 09:42.710]  and it will be up to the originating service provider to do the key management there.
[09:42.710 --> 09:47.110]  And so calls are routed in a few ways. So basically between the originating service
[09:47.110 --> 09:51.190]  provider and the terminating service provider, you might remember from that early slide that
[09:51.190 --> 09:55.870]  there's like all these kind of routes that a call can take. And the way that that happens
[09:55.870 --> 10:00.330]  is there's something called the LNP or local number portability. And this is what people
[10:00.330 --> 10:05.550]  are using to both track whether numbers have been ported between carriers, but it also works as kind
[10:05.550 --> 10:10.610]  of a DNS like lookup to look up phone numbers so that you can then route calls to the right
[10:10.610 --> 10:15.390]  service provider. And usually the originating service provider, it's up to them to basically
[10:15.390 --> 10:21.170]  do this routing. The onus is on them to decide on the route that a call is going to take. They're
[10:21.170 --> 10:27.570]  usually using something called least cost routing. Twilio uses like an inter-exchange carrier.
[10:27.710 --> 10:32.490]  There's vendors that allow you to do this to route calls. I don't want to get into that too much,
[10:32.490 --> 10:36.830]  but basically when it is being passed through the other service providers in the middle there,
[10:36.830 --> 10:40.690]  it is just being passed through. There's not additional validation in the middle there.
[10:40.690 --> 10:46.190]  They're just passing the call through. And then on the other side of things, the terminating service
[10:46.190 --> 10:52.930]  providers then has their own verification service. And the verification service is what contacts the
[10:52.930 --> 10:59.210]  certificate authority and uses the certificate authority's authority there to then verify
[10:59.210 --> 11:04.530]  whether or not the call that came into them is a valid signed call. And so certificate authorities
[11:04.530 --> 11:10.690]  are being chosen by ADIS. That's the Alliance for Telecommunications Industry Solutions. And so
[11:10.690 --> 11:15.290]  this is a standards body that authored Shaken. So some of the certificate authorities that have
[11:15.290 --> 11:20.290]  been chosen are people like Newstar and Transnexus. I think there's a few others that haven't been
[11:20.290 --> 11:24.930]  publicly announced yet. And these are similar to the certificate authorities that administer TLS
[11:24.930 --> 11:30.230]  certificates like Let's Encrypt. And so then when a call reaches a terminating service provider,
[11:30.230 --> 11:36.290]  it's up to the client. So this would be somebody like Apple or Google to decide how to display that
[11:36.290 --> 11:40.930]  the calls are trusted. And so this could be something like, hey, I've got a checkmark next
[11:40.930 --> 11:45.890]  to this call. We display something like you saw on an early slide there that says there's a verified
[11:45.890 --> 11:53.830]  caller here. You could do something like a lock that we have in browsers with TLS, HTTPS sites.
[11:53.830 --> 11:58.350]  So there's different options here. And that has not been standardized in terms of how to signify
[11:58.350 --> 12:02.910]  this to consumers that these calls are not spoofed. And so I think that's going to be one of
[12:02.910 --> 12:10.490]  the interesting challenges that we see as this gets rolled out more is how do we build this trust
[12:10.490 --> 12:14.710]  on the consumer end of things and display this to them in a consistent way so that they know what
[12:14.710 --> 12:20.530]  to expect. So let's get into a little bit of the weeds of how this actually works from the technical
[12:20.530 --> 12:25.830]  perspective. So this is what a SIP header looks like currently. You can see the metadata included
[12:25.830 --> 12:32.930]  there. Just a reminder, SIP is the way to initiate VoIP calls or a way to initiate VoIP calls.
[12:33.030 --> 12:38.090]  But note the from here. So the problem here, Ray, is that the from number can be spoofed.
[12:38.090 --> 12:42.890]  And that happens if either the originating service provider allows it, isn't doing any
[12:42.890 --> 12:48.070]  validation on that. There might be those legitimate reasons for that. But they basically want to make
[12:48.070 --> 12:52.570]  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:04.710]  alone. A lot of the long-tail service providers might not be doing this validation.
[13:05.770 --> 13:10.830]  And so what Shaken does is it introduces a new identity header. And this is in the form of a base64
[13:10.830 --> 13:15.650]  encoded JSON web token. And I'm going to focus on just some of the information that's encoded in
[13:15.650 --> 13:21.610]  the middle section here. And so the information that's encoded there includes things like the
[13:21.610 --> 13:27.090]  attestation level. And so this is in the header. And we'll talk more about what the attestation
[13:27.090 --> 13:33.110]  level is on the next slide. But this is basically the crux of whether or not we trust this call.
[13:33.110 --> 13:36.810]  But it also includes some additional metadata, like who the call is going to,
[13:36.810 --> 13:44.270]  who placed the call. And then importantly, the origination ID. This is for the originating
[13:44.270 --> 13:50.150]  service provider's underlying customer. And so this is set by the originating service provider.
[13:50.150 --> 13:54.810]  And so the originating service provider, the OSP there, is really putting their reputation on the
[13:54.810 --> 13:59.510]  line saying, hey, this is my customer that is placing this call and I'm giving them this level
[13:59.510 --> 14:06.010]  of attestation. And this is important because this ID makes it near instant to identify bad actors
[14:06.010 --> 14:10.870]  because you can trace back the call to the underlying customer. And this is what's going
[14:10.870 --> 14:17.750]  to allow us to enforce the Truth in Caller ID Act. And so not only does Shaken allow you to build
[14:17.750 --> 14:24.130]  trust in calls that aren't spoofed, but it also allows a lot of the enforcement side of things
[14:24.130 --> 14:29.090]  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:46.350]  So A is the highest level of attestation, of course. And so this is saying, I know who this
[14:46.350 --> 14:52.190]  customer is and I know they can use this number that they are calling from. And so that is what
[14:52.190 --> 14:57.630]  you would assume most of the legitimate business calls being placed are. Attestation levels B and
[14:57.630 --> 15:04.850]  C have some less level of trust in the call, but this is still likely to be a less fraudulent call
[15:04.850 --> 15:11.270]  if it's signed with any of these attestation levels than if it wasn't signed at all. And so
[15:12.170 --> 15:16.550]  generally, I think what, and this is where we don't have a lot of standardization around this
[15:16.550 --> 15:23.350]  yet, but the clients, so the Googles, the Apples, are going to have to decide in conjunction with
[15:23.350 --> 15:28.930]  the carriers, the Verizons, the T-Mobiles, these types of people, how to display trust. And likely
[15:28.930 --> 15:32.950]  what's going to happen is that they're only going to display a checkmark or a verified caller
[15:32.950 --> 15:41.130]  if there is that attestation level A. So new technology is really great, but we need to
[15:41.130 --> 15:46.390]  make sure that people are actually implementing this. And so one of the things that is good about
[15:46.390 --> 15:51.710]  this is it puts the onus on businesses to do the implementation and not as much on the consumers to
[15:52.390 --> 15:57.150]  increase consumer protections. But the main way that we're going to ensure that businesses
[15:57.150 --> 16:01.990]  implement this is with the TRACED Act. And so this is the Telephone Robocall Abuse Criminal
[16:01.990 --> 16:08.210]  Enforcement Deterrence Act. It was passed by the Senate last May, passed by the House and signed
[16:08.210 --> 16:13.490]  into law in December of 2019. So I think it was like December 30th of 2019, it was signed into
[16:13.490 --> 16:20.090]  law. And what it did is gave a timeline that started at that point. So basically, you can think
[16:20.090 --> 16:28.790]  of the beginning of this year, it gives telecom companies 18 months to implement shaken and stir.
[16:28.790 --> 16:34.610]  And so you can think mid-2021 is kind of when the deadline for this is. A lot of bigger companies
[16:34.610 --> 16:41.050]  have been working on this for a while, but it's still going to start to enforce the deadline in
[16:41.050 --> 16:48.110]  mid-2021, assuming that everything goes as planned. 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:03.570]  So the authentication requirements for the TRACED Act depend on the type of call. So if it's VOIP,
[17:03.570 --> 17:08.590]  the requirements there is that you have to implement shaken and stir. But they do acknowledge
[17:08.590 --> 17:12.630]  that there isn't really a good solution for non-VOIP calls yet. And there are a lot of
[17:12.630 --> 17:18.210]  non-VOIP calls that are on the PSTN. And so NuSTAR has a solution called Stir Out of Ban
[17:18.210 --> 17:23.450]  for non-VOIP authentication. If you are a company that is placing non-VOIP calls,
[17:23.450 --> 17:28.990]  there's things that you can look into here for you or your customers. But definitely, I think
[17:29.450 --> 17:33.090]  that's one of the challenges to getting this implemented, is not everything is just going to
[17:33.090 --> 17:38.690]  be able to implement shaken and stir. And that's kind of what I wanted to get into now,
[17:38.690 --> 17:42.990]  which is what are the limitations of this technology? First being, you know, according
[17:42.990 --> 17:48.010]  to my curmudgeonly coworker, Randy, who's been working in telecom for many, many years,
[17:48.010 --> 17:53.150]  the phone network is kind of an ungodly beast. And so it's, you know, a collection of wires that
[17:53.150 --> 17:59.590]  has been rapidly expanding for over 100 years. And so there is this kind of situation that we've
[17:59.590 --> 18:03.690]  run into where there isn't a standard technology that's being used for all the calls. And so we
[18:03.690 --> 18:08.730]  can't just flip the switch and change everything over to be suddenly authenticated. And part of
[18:08.730 --> 18:14.410]  that ungodly beast is this thing called time division multiplexing, or TDM. This is essentially
[18:14.410 --> 18:19.190]  the opposite of VOIP. It's old school hardware that's been around for 50 years. It's baked into
[18:19.450 --> 18:25.510]  a lot of enterprise private networks. And the TRACED Act explicitly acknowledges TDM as a
[18:25.510 --> 18:30.670]  potential burden to implementing shake and stir. So they said that the burdens are barriers to the
[18:30.670 --> 18:35.430]  implementation, including for providers of voice service to the extent the networks of such
[18:35.430 --> 18:40.990]  providers use time division multiplexing. Fancy language in the bill that basically says, we get
[18:40.990 --> 18:46.450]  it. This might be hard for people that aren't using VOIP. And then another challenge that we
[18:46.450 --> 18:50.270]  have is that there just is this long tail of service providers. Like this is something that
[18:50.270 --> 18:55.330]  companies like Twilio and Verizon, Comcast, other large companies have been working on for
[18:55.330 --> 18:59.930]  months. What happens when you're a smaller scale service provider that's running limited
[19:00.650 --> 19:06.550]  infrastructure? You might have different access points to the PSTN that aren't going to be VOIP,
[19:06.550 --> 19:11.630]  like I said. And so of the 4,000 service providers in the U.S. alone, I don't know
[19:11.630 --> 19:18.350]  what percentage of those is going to be compliant by mid-2021. So the requirements to
[19:20.550 --> 19:25.190]  comply with this law, it does require significant investment. And I don't know if we can reasonably
[19:25.190 --> 19:28.890]  expect that everybody will be able to make that investment in time.
[19:29.870 --> 19:35.190]  And then there's all these other problems. The biggest problem is in the U.S. right now. But
[19:35.190 --> 19:40.370]  this is also a problem in places like UK and Norway. And I haven't really heard of any initiatives
[19:40.370 --> 19:46.270]  outside of North America to address this. There are starting to be some initiatives to implement
[19:46.270 --> 19:52.650]  this in Canada. But maybe this is something that if your country has a solution for this,
[19:52.650 --> 19:56.510]  reach out. I'd love to hear about what you're doing for enforcement there.
[19:56.510 --> 20:00.290]  But there's other things that we have to think about, like what about ported numbers,
[20:00.290 --> 20:04.590]  the international side, like I mentioned, and also text messages. There's other communication
[20:04.590 --> 20:07.910]  channels that don't have the same type of authentication.
[20:10.570 --> 20:15.390]  So the FCC's number one complaint right now is robocalls, but the government is obviously a
[20:15.390 --> 20:21.950]  little distracted with other global pandemics right now. But I think in terms of that department,
[20:21.950 --> 20:26.390]  this is something that they have a priority and a motivation to fix.
[20:26.430 --> 20:32.490]  And so like I said, the timeline for enforcement here is that towards the end of 2020 or into 2021,
[20:32.490 --> 20:37.650]  we'll start to see more people start to implement this. And you might start to see calls coming
[20:37.650 --> 20:42.050]  through already on your phone that might have a checkmark or might have an indication that
[20:42.050 --> 20:49.310]  they're being signed. So what can you do in terms of implementing shake and stir for your business?
[20:49.310 --> 20:54.850]  Talk to your service provider, whoever is doing your telephony. Most businesses probably won't
[20:54.850 --> 20:58.950]  have to do much in terms of implementation. A lot of the onus is going to be on the service
[20:58.950 --> 21:03.810]  providers themselves. You might have to go through with some additional verifications and like KYC,
[21:03.810 --> 21:08.670]  know your customer type stuff with your service provider. So at Twilio, we'll need you to create
[21:08.810 --> 21:12.750]  a business profile that has some additional details about your account before we would
[21:12.750 --> 21:20.120]  give you and start signing your calls with the highest attestation. And then there's some
[21:20.120 --> 21:25.500]  precautions that you can take as just application security professionals. So you can protect your
[21:25.500 --> 21:30.620]  numbers from web scraping bots. Don't assign sequential numbers to your employees. That's
[21:30.720 --> 21:37.140]  a way that people can kind of guess which employees might have lines at your company.
[21:37.420 --> 21:41.760]  And then you can use actual authentication in your call centers. This is another way that you can
[21:41.760 --> 21:48.380]  protect your business from phishing. This is something that I could talk about for many,
[21:48.380 --> 21:53.540]  basically. We'll only ask for a consumer, you know, date of birth and email in order to verify
[21:53.540 --> 21:58.060]  the customer. And so there's a lot of other things you can do to actually authenticate people on
[21:58.060 --> 22:03.460]  either end of the call. And then if you know what a PBX is and you have one, you might look into
[22:03.940 --> 22:09.640]  installing the FCC blacklist database on that. Some controversy around whether or not you want
[22:09.640 --> 22:14.480]  to do that. It's hard to get off the blacklist database if you're on there. But this is something
[22:14.480 --> 22:19.880]  that you may or may not have to worry about. And then there is some ongoing legislation.
[22:20.060 --> 22:25.180]  But things have been pretty quiet from the FCC this year. They did recently, somewhat recently,
[22:25.180 --> 22:30.680]  like in the last year, give telcos the authority to block unwanted calls without explicit subscriber
[22:30.680 --> 22:35.920]  permission. And so, you know, AT&T, Verizon, T-Mobile in the U.S., they can now decide, hey,
[22:35.920 --> 22:40.580]  we're going to send this to basically like a spam folder without ever notifying you that the call
[22:40.580 --> 22:45.960]  came in and I don't need you, Kelly, to tell me that that's okay. And then like I mentioned,
[22:45.960 --> 22:49.580]  in terms of timeline for the Trace Stack, the enforcement will start to begin at the end of
[22:49.580 --> 22:57.620]  2020. Last update from the FCC on this was March 31st. And this reaffirmed their call to implement
[22:57.620 --> 23:04.160]  Shaken and Stir, but it did already grant an exception for and an extension for small voice
[23:04.160 --> 23:08.560]  service providers. And I don't know what that means. I don't know exactly how they're going
[23:08.560 --> 23:13.720]  to decide who is a small voice service provider, but they are already thinking about, you know,
[23:13.720 --> 23:18.880]  this was three months after the bill was signed into law. They're already saying, hey, maybe this
[23:18.880 --> 23:26.240]  timeline isn't reasonable. So while I do think that a lot of larger telecom providers will start to
[23:26.240 --> 23:32.760]  sign calls within the end of this year, I do think that there is going to be an exception for
[23:32.760 --> 23:36.880]  that long tail of service providers and not everything is going to be a signed call
[23:36.880 --> 23:43.960]  before, you know, the end of 2021. There are a couple of things you can do as a consumer to
[23:43.960 --> 23:49.520]  protect yourself today. You can install one of these apps depending on how much you trust them.
[23:49.520 --> 23:53.360]  A lot of times you have to give them basically complete control over your phone, so your
[23:53.360 --> 23:59.100]  mileage may vary there. But things like NovoRobo, RoboKiller, CallApp, you know, companies like
[23:59.100 --> 24:03.780]  AT&T have a partnership with a company called Haya that does, you know, some protection against
[24:04.440 --> 24:11.240]  spam calls. Of course, a lot of consumer telecoms are starting to upsell spam detection services,
[24:11.240 --> 24:17.020]  so Verizon offers their CallFilter Plus for the low, low price of $3 a month. But, you know,
[24:17.020 --> 24:21.420]  these are things that you can look into installing on your phone if this is something that is a huge
[24:21.420 --> 24:26.100]  annoyance to you right now. So like I said, unfortunately, I don't think this is going to
[24:26.100 --> 24:30.380]  solve all problems right away, but I think people are really optimistic that Shaken and Stare will
[24:30.380 --> 24:36.840]  help restore trust in telephony, because not only is it going to help, you know, mitigate spam calls
[24:36.840 --> 24:41.620]  that are coming into your phone, but for those wanted calls for, you know, the calls that you
[24:41.620 --> 24:48.120]  want to see that might be from unknown numbers, there's going to be a renewed trust in some of
[24:48.120 --> 24:52.820]  those phone calls. And so there is that motivation from businesses to restore that type of trust so
[24:52.820 --> 24:58.820]  that people will answer the calls. Hopefully this is a good overview in terms of what you can expect
[24:58.820 --> 25:04.060]  from Shaken and Stare. If you have any questions, you can find me on Twitter. 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:19.180]  All right, welcome back everybody. That was What If We Had TLS for Phone Numbers? An Introduction
[25:19.180 --> 25:25.120]  to Shaken and Stare by Kelly Robinson. We actually have Kelly with us here right now.
[25:25.140 --> 25:32.420]  If you have any questions, drop them in our Discord Q&A channel down linked in the description
[25:32.420 --> 25:41.940]  below. We've got some questions here. Hi Kelly, great talk. Thank you. Question, working hard to
[25:41.940 --> 25:47.200]  get Scandinavian governments and telcos to have an opinion on Shaken and Stare. A part of the
[25:47.200 --> 25:52.140]  feedback I've gotten is that unless all carriers all over the world implement this, and they all
[25:52.140 --> 25:58.020]  promise not to allow governments to mess with it for spooking purposes, it really won't work.
[25:58.020 --> 26:02.140]  I don't know it well enough yet to either accept that as an answer or tell them they're wrong,
[26:02.140 --> 26:06.580]  but at least I hope and I think that it will assist in reducing the problem. What's your take
[26:06.580 --> 26:11.340]  on this and do you have any solid arguments I can use in order to speed up their process of
[26:11.340 --> 26:19.100]  considering this? Yeah, so one of the things that we hear a lot from customers, and so like as
[26:19.100 --> 26:23.180]  somebody that like works at an originating service provider, this is something that our customers are
[26:23.180 --> 26:28.980]  actually like interested in us implementing, specifically because of like not the like
[26:28.980 --> 26:34.960]  consumer, like I'm sick of receiving spam calls side of things. I don't know like what the,
[26:34.960 --> 26:39.220]  you know, Scandinavian countries, like how many complaints you're getting about this. The reason
[26:39.220 --> 26:44.720]  like the FCC is motivated to do this is because they just get a lot of complaints about robocalling.
[26:45.200 --> 26:49.160]  But on the flip side of that, from the company side of things, there's a lot of motivation there
[26:49.160 --> 26:55.040]  to be like, hey, I want my customers to actually answer the calls that I'm like sending them.
[26:55.040 --> 27:03.720]  And so if we reduce calls for that are spam calls, then we might be able to get calls to get
[27:03.720 --> 27:09.640]  answered. And so there is that like, in America, capitalist, you know, type of motivation there to
[27:09.640 --> 27:13.660]  say, hey, this might actually be good for businesses. And so there's been like some
[27:13.660 --> 27:20.020]  lobbying on that side of it, too. So if there's like, a big reason for companies that you know,
[27:20.020 --> 27:23.840]  in the countries that you operate to do this, like, there obviously are going to be some of
[27:23.840 --> 27:27.580]  those network effects of like, hey, until everybody does this, it's not going to be a
[27:27.580 --> 27:32.420]  perfect solution. But I agree with you, I think it's going to help. And I think it might help with
[27:32.420 --> 27:38.340]  like, the, you know, we might get to a point where the terminating service providers decide,
[27:38.340 --> 27:42.920]  hey, like, I'm not going to like allow calls through, or maybe we'll have a point where the
[27:42.920 --> 27:48.200]  consumers get to say, hey, I'm only going to let you like ring calls through to my phone.
[27:48.200 --> 27:52.940]  If it has that like a level attestation, we might see this. And this is where like,
[27:52.940 --> 27:56.500]  we don't really know yet, right? Like, we might or couldn't see this get to the point where you
[27:56.500 --> 28:01.360]  have more fine grained control as a consumer, almost like you do on your email inbox of saying,
[28:01.360 --> 28:06.440]  like, maybe I have like a phone spam folder that I need to like, don't like look at unless I
[28:06.440 --> 28:11.600]  specifically go check the missed calls in that like, unsigned folder, like things that aren't
[28:11.600 --> 28:19.820]  signed by shaken. Yeah, very interesting. The next question is along those same lines.
[28:19.820 --> 28:26.520]  Biggest question for me is how do we solve the robocall scam problem globally? Privacy laws and
[28:26.520 --> 28:31.800]  even new tech that's only implemented in one country isn't going to do anything. Do you think
[28:31.800 --> 28:38.800]  maybe calls might be blocked from outside of the country if they're not signed? Yeah, I don't know.
[28:38.800 --> 28:43.180]  I mean, I think that's going to be one of those things. Like, I don't think right now there's
[28:43.180 --> 28:48.500]  going to be a ton of that happening. You know, obviously, my viewpoint on this is pretty US
[28:48.500 --> 28:53.540]  centric, since I, you know, I live in the US and have done the majority of research on this problem
[28:53.540 --> 28:58.940]  in the US. And this is something that I'm just like, not as familiar about, like, in the US,
[28:58.940 --> 29:03.220]  it's something where the majority of the calls that I get, the vast majority of the calls I get
[29:03.220 --> 29:07.540]  are from other US numbers. I know, obviously, that's not as true in other parts of the country
[29:07.540 --> 29:11.440]  where like, or other parts of the globe where there's like more countries that you would be
[29:11.440 --> 29:17.280]  receiving more calls from other like country codes. So yeah, I don't I don't think we're
[29:17.280 --> 29:21.860]  going to get to a point where like, it's just straight up blocking things because they're from another
[29:21.860 --> 29:27.540]  country. But you know, that might be something where things like I said, could flip to say, like
[29:27.540 --> 29:33.980]  the consumer can decide, hey, I want to, you know, allow these types of calls or, you know, maybe
[29:33.980 --> 29:38.000]  this is something that like carriers will come to an agreement with, like, there's already a lot
[29:38.000 --> 29:43.520]  of agreements between carriers as they switch calls between different networks to get them to
[29:43.520 --> 29:48.760]  other countries. Like, you know, that's all part of the PSTN that you have to have that those
[29:48.760 --> 29:53.140]  switches kind of in place to talk to other carriers and other parts of the globe. So
[29:53.140 --> 29:57.280]  yeah, there's just there, it's unfortunate, but there is just a lot that's unknown about how this
[29:57.280 --> 30:04.440]  is going to play out. But good question. Yeah, thank you. And then let's see, we've got another
[30:04.440 --> 30:10.120]  I was curious, who enforces fines under the TRACED Act? Do I need to take the spammer to
[30:10.120 --> 30:16.480]  court myself? Or will the government do that for me? That's a good question. I don't fully know
[30:16.480 --> 30:21.360]  the answer to that. But it might be something that the FCC would be involved in. And that's
[30:21.360 --> 30:27.420]  as much as I will speculate on that until I know more for sure.
[30:29.500 --> 30:37.400]  Cool. Well, there's some more questions here. Yeah, all right. What are potential
[30:37.400 --> 30:42.920]  attack vectors to protect against? Example for TLS and attack vectors getting a bad root
[30:42.920 --> 30:48.600]  certificate or bad root CA certificate in your trust store? Is there a similar problem?
[30:49.980 --> 30:55.800]  This is another one that I haven't thought too much about yet. But I'll definitely take that
[30:55.800 --> 30:59.920]  back to the team that's implementing this at Twilio and see if they have any thoughts about
[30:59.920 --> 31:06.420]  that. And maybe issue a follow up to you. Yeah, that's interesting. So depend on how it's
[31:06.420 --> 31:13.100]  implemented. Yeah, I know there was actually somebody that talked about this last year at the
[31:13.100 --> 31:17.440]  crypto privacy village in terms of like, and they focused on like a lot of the
[31:18.680 --> 31:22.980]  like the actual like the originating service provider has to set up like their own PKI and
[31:22.980 --> 31:27.500]  stuff around it. And they were like, that can be really hard. But that person was also like a PKI
[31:27.500 --> 31:33.240]  vendor of like, I can help you with this. So I'm not sure how hard that part actually is.
[31:34.740 --> 31:40.380]  All right. Well, thank you for joining us today. If anybody has any more questions,
[31:40.380 --> 31:43.660]  direct them to the Discord Q&A channel.
[31:43.900 --> 31:47.440]  And Kelly is there and she might be able to answer some of your questions. Thanks, everyone for
[31:47.440 --> 31:51.960]  joining us. And next up on the screen.