[00:00.000 --> 00:02.160]  So, my name is Tishar Joyce.
[00:02.720 --> 00:05.200]  I am an assistant professor at the City College of New York.
[00:05.400 --> 00:06.940]  Yes, I know, I'm an academic.
[00:07.140 --> 00:07.960]  You can roast me later.
[00:09.300 --> 00:15.700]  I am so excited to be here today to talk to you about our ongoing work on group mesh messaging for large-scale protests.
[00:16.140 --> 00:20.000]  This is joint work with my collaborators at City College, at Johns Hopkins, and at Harvard.
[00:20.400 --> 00:25.140]  And I wanted to point, just give a quick shout-out to my student collaborator, Sarah, who worked on the slides.
[00:25.640 --> 00:26.580]  Okay, let's begin.
[00:27.980 --> 00:29.060]  Thank God that worked.
[00:29.600 --> 00:30.180]  Oh, laser pointer, nice.
[00:30.500 --> 00:31.480]  Okay, so...
[00:32.760 --> 00:39.440]  Large-scale protests are one of the most effective ways of combating authoritarian power structures.
[00:39.720 --> 00:42.340]  We've seen them for racial justice.
[00:42.340 --> 00:43.840]  We've seen them for women's rights.
[00:44.080 --> 00:46.020]  We've seen them for democratic representation.
[00:46.360 --> 00:49.840]  They increase global and national visibility of major issues.
[00:50.800 --> 00:56.320]  And in these scenarios, protests are organized through communication.
[00:56.320 --> 01:02.360]  This communication becomes necessary to identify locations for protesters' safety.
[01:02.500 --> 01:02.580]  Right?
[01:02.720 --> 01:05.070]  Like, where are medics for protesters?
[01:05.680 --> 01:07.300]  Where are the police operating?
[01:07.580 --> 01:10.400]  Where are protesters gathering for new actions?
[01:10.820 --> 01:13.660]  Are my friends and family safe during the protest?
[01:14.520 --> 01:19.240]  So, with this in mind, governments try to prevent this protestor communication.
[01:19.980 --> 01:36.240]  So, a recent example in 2022, during the Masa Amini protests, there was widespread Internet shutdown in Iran, because they wanted to suppress the spreading of information about all of the police brutality and the security forces' killings.
[01:36.760 --> 01:42.800]  So, it's clear that governments want to weaponize, basically, Internet shutdowns to stifle political expression.
[01:43.740 --> 01:46.480]  And the way you do this is actually really just non-technical.
[01:47.040 --> 01:47.120]  Right?
[01:47.240 --> 01:50.660]  All you gotta do is phone up the Internet service provider and say, shut it down.
[01:50.900 --> 01:51.180]  Right?
[01:51.560 --> 01:52.840]  It's basically free.
[01:53.200 --> 01:54.560]  So, it's a really easy thing.
[01:54.740 --> 01:57.000]  It's basically the first thing in the censorship toolbox.
[01:58.640 --> 02:02.620]  So, going a step further, governments also want to intercept this type of communication.
[02:02.620 --> 02:08.420]  They want to know ahead of time, before protests happen, so they can proactively try to suppress them.
[02:09.520 --> 02:11.220]  So, this can be done in a lot of ways.
[02:11.560 --> 02:22.340]  You can do wiretaps, you can do backdoors and technologies, or you can do stingrays, which are used here in the good ol' US of A, which are basically systems that act like cell towers.
[02:22.520 --> 02:29.760]  They intercept subscriber communications and are able to collect communications information, metadata, what have you.
[02:30.380 --> 02:36.680]  And this can be abused by security forces to determine who was at a protest and who wasn't.
[02:37.920 --> 02:41.640]  And all this is possible because it's a centralized system, right?
[02:41.720 --> 02:45.400]  If I want to send a message to the back of the room, it has to go to a cell tower first.
[02:46.340 --> 02:49.460]  And this cell tower is something that law enforcement can just sit on.
[02:49.460 --> 02:52.520]  And they can prevent or intercept communication that way.
[02:53.900 --> 03:08.380]  So, it is evident, given these threats, that we need communication systems that are, one, resistant to government attempts to cut communications, meaning that they can function without some kind of single point of failure, like a cell tower or a Wi-Fi router.
[03:09.380 --> 03:15.180]  And these systems are challenging to meaningfully intercept, meaning that they provide certain security and privacy properties.
[03:17.620 --> 03:19.080]  So, here's our statement of want.
[03:19.160 --> 03:24.280]  We want an anonymous mesh communication system designed for large-scale protests, right?
[03:24.480 --> 03:27.760]  I think a lot of us here are familiar with anonymity as a property, right?
[03:28.120 --> 03:34.560]  Here, we want to basically make it difficult to identify protesters because identification is enough to get thrown in jail.
[03:35.400 --> 03:38.000]  But we also want a mesh communication system.
[03:38.140 --> 03:39.580]  So, what do I mean by mesh?
[03:40.360 --> 03:46.280]  So, I talked about how a centralized system wouldn't be very cash money, so we need something a little different.
[03:46.600 --> 03:49.640]  What if the nodes themselves could talk to each other?
[03:50.320 --> 03:55.840]  What if the smartphones, each in this room, could all talk to each other to send messages between each other?
[03:56.040 --> 03:58.020]  And this is known as a mesh network.
[03:58.740 --> 04:05.160]  And they function without any centralized infrastructure and allow us to maybe communicate without censorship.
[04:05.680 --> 04:07.180]  Okay, this is a good idea.
[04:07.600 --> 04:13.840]  But now that we don't have a centralized infrastructure, we have to be more thoughtful about how we send information, right?
[04:13.900 --> 04:15.400]  We can't just send it to a cell tower anymore.
[04:16.200 --> 04:19.380]  So, what if we flood the traffic to the network, right?
[04:19.640 --> 04:26.740]  If I'm standing here, I send to everybody in the first row, everybody in the first row sends to the second row, backwards, all the way to the back of the room, right?
[04:26.740 --> 04:32.420]  So, in this scenario here, one hop, two hops, three hops, right?
[04:33.100 --> 04:37.340]  So, this gets a lot of the information out very quickly, but there's a lot of repeat traffic.
[04:37.740 --> 04:42.640]  Well, if suppose I'm just talking to this person and I'm over here, then I've actually had a lot of wastage, right?
[04:42.740 --> 04:43.860]  That doesn't actually need to communicate.
[04:44.180 --> 04:45.100]  We'll get to that later.
[04:46.920 --> 04:48.820]  Next solution is routing, right?
[04:48.880 --> 04:50.000]  This is kind of what the Internet does.
[04:50.380 --> 04:51.480]  It's not kind of what the Internet does.
[04:51.580 --> 04:52.360]  It is what the Internet does.
[04:52.360 --> 04:58.700]  It directly sends a message from a packet to a destination, intentionally routing it there.
[04:59.560 --> 05:00.680]  So, this is good.
[05:00.780 --> 05:02.240]  This is a lot more efficient, right?
[05:02.620 --> 05:05.440]  But it does require the receiver know where the send...
[05:05.440 --> 05:05.760]  Excuse me.
[05:05.940 --> 05:09.400]  The sender knows where the receiver is, which is non-trivial.
[05:09.560 --> 05:11.080]  And I'll get to that in a second as well.
[05:11.980 --> 05:12.960]  Alright, so flooding and routing.
[05:14.320 --> 05:20.860]  But if I had no protections, just because I've swapped to a mesh network doesn't mean I've achieved privacy.
[05:21.660 --> 05:23.340]  Traffic can still be intercepted.
[05:23.660 --> 05:25.980]  What if the person in the third row is a cop?
[05:26.540 --> 05:28.700]  And I'm sending a message to the back.
[05:28.860 --> 05:32.880]  If any traffic that passes through, that person can be intercepted.
[05:33.300 --> 05:39.860]  Now, it doesn't mean I can't intercept everything like it could with a centralized infrastructure, but I still can intercept something.
[05:40.800 --> 05:45.380]  If I don't encrypt my communication, the person in the third row can just read everything, and I'm toast.
[05:46.220 --> 05:52.740]  Or if I do encrypt it, maybe there's some metadata information such as senders and receivers, that is similarly incriminate.
[05:53.980 --> 05:55.480]  So there's a lot of nuance here.
[05:55.840 --> 05:58.980]  But we're not the first people to think about anonymous mesh messaging.
[05:59.260 --> 06:01.920]  There are quite a few academic works out there.
[06:02.900 --> 06:07.080]  So I'm going to talk about two of them right now and kind of give you a flavor for what has been studied already.
[06:08.020 --> 06:16.320]  So the first is Pradeep et al, who created a system that allows for flooding-based protocol over Wi-Fi Direct.
[06:17.520 --> 06:21.640]  And their kind of innovation was to prevent denial of service tax.
[06:21.980 --> 06:24.320]  And this is actually really important in a mesh network.
[06:24.500 --> 06:27.780]  If you think about it, what if you don't have this kind of protection?
[06:28.080 --> 06:32.320]  The law enforcement can just join the network as adversaries and spam it full of traffic.
[06:32.640 --> 06:36.820]  Basically drowning out any legitimate traffic, slowing down any routing, right?
[06:37.140 --> 06:38.440]  So it's an important threat model.
[06:39.500 --> 06:44.540]  And then Perry et al also have studied mesh networking in the anonymity setting.
[06:44.880 --> 06:50.460]  And their solution is focused on reducing message overhead by reducing the overhead of flooding.
[06:50.660 --> 06:51.920]  And I'll get to that in a second.
[06:53.500 --> 07:01.680]  But unfortunately, these works don't fully meet the uses, cases of large-scale protests like the ones I'm kind of describing.
[07:02.040 --> 07:02.740]  Here's why.
[07:04.180 --> 07:08.220]  These two former papers only evaluated a few messages every 30 seconds.
[07:08.400 --> 07:10.080]  Pradeep et al, about five messages.
[07:10.540 --> 07:12.080]  Perry et al, about 200 messages.
[07:12.940 --> 07:17.180]  Protests are bigger than five or 200 people, at least the ones I'm talking about, right?
[07:17.760 --> 07:24.140]  Your real-world protests are going to entail more participants, more messages, shorter time periods, right?
[07:24.360 --> 07:30.740]  So when we're building something for large-scale protests, we need something like 10,000 messages every 30 seconds, right?
[07:30.820 --> 07:36.580]  Because that's the level of scale that we want for this to be usable for this specific use case.
[07:38.060 --> 07:38.580]  Okay?
[07:39.580 --> 07:43.980]  Next, I would argue that these systems have not been evaluated in realistic models.
[07:44.320 --> 07:46.220]  So we're academics.
[07:46.440 --> 07:48.000]  You have to use the data that we have.
[07:48.220 --> 07:50.800]  So Pradeep et al used everyday cell tower data.
[07:51.420 --> 07:53.940]  And if you don't have data, you can make your own data.
[07:53.940 --> 08:03.680]  So Pradeep et al used simulations where they have static crowds, meaning everyone's kind of standing still in a grid, and constant send intervals, meaning every 30 seconds, someone sends a message.
[08:04.000 --> 08:06.120]  This is what they used for their evaluation.
[08:06.900 --> 08:10.120]  But I would argue this is actually not how protests function, right?
[08:10.200 --> 08:13.500]  If you've been to a protest, people don't stand in one place, right?
[08:13.560 --> 08:16.380]  A lot of us are ADHD, so we just kind of bounce around.
[08:17.580 --> 08:19.920]  So we don't maintain static, consistent positions.
[08:20.040 --> 08:23.360]  We don't move or send messages like on a normal day, right?
[08:23.900 --> 08:29.740]  You know, if it was a normal Tuesday, that data would not look like if it was a large-scale protest down a city block.
[08:30.560 --> 08:34.140]  So we need to create realistic mobility and traffic models.
[08:35.340 --> 08:36.460]  So how do we do this?
[08:36.740 --> 08:40.820]  Well, we want to draw on the experiences of past protesters.
[08:41.460 --> 08:43.720]  What have they done in the past?
[08:43.820 --> 08:44.780]  How have they operated?
[08:45.040 --> 08:51.760]  How can we use that to build simulations and models that help us identify how to build mesh networking in this setting?
[08:52.100 --> 08:53.500]  And we'll get to that at the end of the talk.
[08:54.560 --> 08:56.040]  And finally, Pradeep et al.
[08:56.100 --> 08:56.660]  and Perry et al.
[08:56.760 --> 08:58.700]  only consider pairwise communication.
[08:58.920 --> 08:59.740]  Two people talking.
[08:59.960 --> 09:00.920]  Alice talking to Bob.
[09:01.540 --> 09:04.020]  And this is usually okay, right?
[09:04.240 --> 09:07.820]  But the big thing is protesters work in groups, right?
[09:08.240 --> 09:10.560]  So there's a really wonderful paper by Albrecht et al.
[09:10.560 --> 09:15.460]  where they surveyed protesters from the 2019 Hong Kong anti-e-lab protests.
[09:15.700 --> 09:17.860]  So if you're not familiar, this was a major protest.
[09:18.060 --> 09:23.020]  Over 2 million people participated over the course of this in protest of the new security bill.
[09:24.100 --> 09:30.740]  And these researchers interviewed protesters and asked them, what kind of security tools did you use?
[09:30.880 --> 09:31.780]  How did you communicate?
[09:33.060 --> 09:44.560]  So we discovered, or they discovered, I should say, that protester messaging is really organized into small groups of 25 people or fewer, or large groups in the thousands, maybe tens of thousands.
[09:45.300 --> 09:48.580]  So with this in mind, we can't just go with pairwise communication.
[09:48.580 --> 09:50.360]  We need to support groups.
[09:50.580 --> 09:54.740]  But technically, that requires additional infrastructure to support group messaging.
[09:55.340 --> 10:04.360]  So we talked about group key management for large-scale protest use case, as well as routing protocols that help messaging in this group setting.
[10:04.740 --> 10:07.160]  And these are our two technical contributions, which I'll talk about.
[10:08.100 --> 10:17.000]  So our solution, which we call Amigo, aims to increase the efficiency, the utility, and the privacy of existing mesh messaging.
[10:17.320 --> 10:20.860]  And the way we do that is by focusing on this group setting.
[10:22.560 --> 10:23.480]  So let's begin.
[10:23.740 --> 10:24.600]  Here's the diagram.
[10:24.960 --> 10:26.420]  It looks like the OSI model.
[10:26.600 --> 10:27.520]  It's not the OSI model.
[10:27.660 --> 10:29.900]  Don't worry for those of you who flunked your computer networking class.
[10:30.980 --> 10:34.880]  So we're going to start bottom-up and go through each layer of our solution.
[10:35.440 --> 10:40.720]  And there's not necessarily security at each layer, but when I talk about security, you'll start to see the threat model.
[10:41.160 --> 10:42.280]  Let's start with the link layer.
[10:42.420 --> 10:42.920]  Pretty easy.
[10:43.380 --> 10:46.480]  The link layer answers the question, how do nodes exchange packets?
[10:47.660 --> 10:49.280]  So how do nodes exchange packets?
[10:50.500 --> 10:53.080]  Well, we have to support smartphones, right?
[10:53.160 --> 10:56.180]  Because we're talking about smartphone mesh networking with a large-scale protest.
[10:56.180 --> 10:57.820]  So what do smartphones support?
[10:58.660 --> 11:00.440]  By and large, they support three protocols.
[11:00.820 --> 11:03.840]  Bluetooth Low Energy, Wi-Fi Direct, Ad Hoc Wi-Fi.
[11:04.580 --> 11:07.700]  And the reason we can support all three is not because we're code gods.
[11:07.940 --> 11:09.820]  It's actually because they all have the similar structure.
[11:10.400 --> 11:18.740]  So the first thing that all of these protocols do is a node advertises its presence by sending some packets saying, I'm here.
[11:19.000 --> 11:20.760]  And that's usually referred to as a beacon.
[11:21.500 --> 11:26.960]  And after it refers to this beacon, another node can be like, hey, I see you, let's start communicating.
[11:27.760 --> 11:30.580]  Basically acknowledges the beacon and sets a channel for communication.
[11:31.460 --> 11:34.780]  And finally, they can start exchanging data between each other.
[11:35.600 --> 11:36.800]  So this is the workflow.
[11:37.240 --> 11:40.180]  Beacon, confirm channel, exchange data.
[11:40.660 --> 11:44.120]  So with that in mind, we can actually just have two packet types in our Amigo system.
[11:44.560 --> 11:48.640]  We have the beacon, which says, hey, I'm nearby, come talk to me.
[11:48.960 --> 11:49.280]  Right?
[11:49.320 --> 11:50.640]  And that's going to be useful in a mesh network.
[11:50.640 --> 11:54.260]  Making everyone aware, discovery, basically, of nearby nodes.
[11:55.260 --> 12:02.080]  And then there are message packets, which entail the exchange of message information, actual communication back and forth.
[12:04.320 --> 12:06.700]  So that was a quick dip into the link layer.
[12:07.200 --> 12:10.440]  Let's talk a little bit more, something interesting, and let's talk about routing.
[12:11.440 --> 12:14.900]  So routing answers the question, who do we send the packets to?
[12:15.140 --> 12:18.780]  How do smartphones route messages through the network?
[12:20.640 --> 12:22.620]  So there are kind of four solutions.
[12:22.940 --> 12:26.740]  There are two existing ones that I'll talk about, and then two new ones that we're thinking about.
[12:27.940 --> 12:33.560]  So the first two are flooding-based solutions, and the easiest one to understand is just a normal flooding-based solution.
[12:33.680 --> 12:38.920]  And this is what I talked about earlier, where everyone just talks about everything all the time, all at once.
[12:39.980 --> 12:42.080]  So let's talk about this in more detail, though.
[12:42.900 --> 12:45.580]  Every message has some parameter called a time to live.
[12:45.820 --> 12:47.800]  You might recognize this from TCP IP.
[12:49.400 --> 12:58.840]  But when a node receives a message that has not reached this time to live parameter, it awaits some delay, and then rebroadcast it to everyone in its vicinity.
[13:01.820 --> 13:06.940]  So I will say that when I say everyone in its vicinity, I really mean everyone in the vicinity.
[13:07.500 --> 13:12.720]  The original sender could also receive the packet because they are still nearby, right?
[13:12.800 --> 13:13.480]  If you're not careful.
[13:14.780 --> 13:18.460]  So this is like something that's going to come up with flooding, is this repeat traffic.
[13:19.180 --> 13:24.580]  Now let's say that we wait some more time, and we're going to do another round of broadcasting.
[13:25.500 --> 13:28.240]  So maybe a different set of parties is now broadcasting.
[13:28.640 --> 13:31.780]  So you can see here, the middle node is getting all of these messages at the same time.
[13:33.440 --> 13:37.280]  And the crazy thing is, some other nodes could also be getting the messages.
[13:37.480 --> 13:42.660]  This node and this node, they could be close enough in range to also broadcast to each other.
[13:43.520 --> 13:47.160]  And the range of something like Bluetooth low energy is between 10 and 100 meters.
[13:47.160 --> 13:50.040]  And that's actually kind of a large range, right?
[13:50.280 --> 13:57.460]  So it's not out of the realm of possibility that these two people, even though they're trying to get a node here, are still going to talk to each other.
[13:58.380 --> 14:03.040]  So there are some clear advantages, before I rag on this too much, to this system.
[14:03.880 --> 14:05.640]  You are going to get great message delivery.
[14:05.880 --> 14:12.900]  If you think about it, you are going to find a path to the destination because you're attempting to contact every single node.
[14:13.980 --> 14:16.240]  And that also gives you a degree of partition resistance.
[14:16.240 --> 14:18.160]  If, you know, ...
[14:21.800 --> 14:25.280]  with a flooding-based protocol, and you get reasonably good latency.
[14:25.660 --> 14:31.640]  If you think about it, you are going to find the shortest path to the destination because we're finding every single path to the destination.
[14:32.580 --> 14:33.960]  So those are the strengths.
[14:34.160 --> 14:36.580]  But by far, the biggest weakness is message overhead.
[14:36.580 --> 14:39.960]  You are generating so much traffic that you just don't need.
[14:40.400 --> 14:43.740]  And because you don't need it, you are clogging the network with waste.
[14:44.580 --> 14:45.060]  Especially...
[14:45.060 --> 14:47.460]  And this is just because you don't know where anyone is in the network.
[14:48.980 --> 14:53.660]  So, with that in mind, some other folks tried to solve this problem.
[14:54.460 --> 15:00.420]  Perry et al introduced a new broadcasting paradigm in their paper, and we're going to term it digest-based flooding.
[15:01.480 --> 15:09.080]  So the core idea here, before I get into the technical details, is you basically tell everyone what messages you have seen.
[15:09.620 --> 15:14.720]  And if there is a message that you have not seen, you try to download it from the other node.
[15:15.280 --> 15:18.900]  So, the way this works is that there's a bloom filter.
[15:19.200 --> 15:22.060]  And if you haven't heard of a bloom filter, it's a probabilistic data structure.
[15:22.440 --> 15:26.700]  And the point of a bloom filter, it's basically just an array of ones and zeros.
[15:27.020 --> 15:27.380]  Okay?
[15:27.880 --> 15:28.860]  So set it to all zero.
[15:29.420 --> 15:33.380]  Anytime you have a message, you take a hash of that message.
[15:33.640 --> 15:35.200]  Converts into a numerical value.
[15:35.480 --> 15:38.700]  You take that numerical value as an index into the array.
[15:40.080 --> 15:44.500]  And then, in that array, you can set that index to 1.
[15:44.680 --> 15:48.020]  So that says, that I have the message at index 26.
[15:49.040 --> 15:50.580]  And you do that for every message you have.
[15:51.980 --> 15:53.820]  So nodes...
[15:53.820 --> 15:58.060]  when they talk to each other, when they beacon to each other, they can say, Here's my digest array.
[15:58.760 --> 16:00.360]  Here are the messages I have seen.
[16:01.160 --> 16:03.780]  And then you can go ahead and compare them.
[16:03.920 --> 16:06.160]  And you can be like, Oh, well, these don't exactly match.
[16:06.300 --> 16:07.760]  It means you have a one where I have a zero.
[16:07.980 --> 16:09.700]  That means you have a message I don't have.
[16:10.600 --> 16:13.460]  Which means, That means you can then go request it from that other node.
[16:13.900 --> 16:15.280]  It's a pretty smart idea.
[16:16.100 --> 16:22.120]  And it does result in better network overhead, because you're only sending exactly the messages you don't have.
[16:22.380 --> 16:25.540]  If you receive that message from someone else, you don't request it.
[16:26.140 --> 16:26.660]  Again.
[16:27.520 --> 16:30.280]  And, you know, the latency of the solution is still pretty good.
[16:30.480 --> 16:31.740]  These digests are pretty simple.
[16:32.480 --> 16:36.180]  And you still get good resiliency because you are still a flooding-based protocol.
[16:36.460 --> 16:39.600]  You are flooding these digests instead of flooding these messages.
[16:39.600 --> 16:42.960]  So eventually you should get everyone to communicate.
[16:44.020 --> 16:46.980]  But you're still not getting, like, great network overhead, right?
[16:47.020 --> 16:47.760]  You're still flooding.
[16:47.960 --> 16:49.940]  You're still clogging with a bunch of excess traffic.
[16:50.320 --> 16:53.960]  Just because these digests are smaller doesn't mean that you aren't wasting bandwidth.
[16:53.960 --> 16:55.640]  You're just wasting maybe less bandwidth.
[16:56.340 --> 16:58.300]  And message delivery might become an issue.
[16:58.460 --> 17:07.780]  For those of you who know a little bit about bloom filters, their probabilistic nature means that there could be some false positives, which means you lose traffic that is destined for the network because of some kind of collision.
[17:07.780 --> 17:10.360]  But if you don't get bloom filters, it's okay.
[17:10.500 --> 17:11.480]  You can just trust me, bro.
[17:13.100 --> 17:13.540]  Okay.
[17:13.540 --> 17:13.980]  So...
[17:15.260 --> 17:15.780]  All right.
[17:15.880 --> 17:17.520]  Flooding-based protocols, pretty good.
[17:17.660 --> 17:19.540]  But can we do better, right?
[17:19.900 --> 17:20.560]  Can we do better?
[17:20.620 --> 17:22.380]  And that's the question we try to answer.
[17:22.920 --> 17:28.780]  So in our work, we're trying to build routing protocols for mesh networking, which really hasn't been looked at systematically.
[17:29.460 --> 17:32.660]  And the first design we're going to propose is static clique routing.
[17:33.700 --> 17:34.140]  So...
[17:34.640 --> 17:36.000]  Cliques... Okay, it's not Mean Girls.
[17:36.320 --> 17:40.540]  But cliques are like groups of nodes where there are several members and one leader.
[17:41.020 --> 17:42.340]  Okay, so maybe it is Mean Girls.
[17:43.100 --> 17:46.680]  But I'm going to say that they're static, meaning that they don't change throughout the protest.
[17:46.940 --> 17:50.600]  And they're predetermined, meaning they're assigned prior to attending the protest.
[17:51.360 --> 17:53.880]  And some of you are already going to be like, but sure, it has flaws.
[17:54.040 --> 17:55.340]  I'm like, okay, yes, it has flaws.
[17:55.680 --> 17:56.560]  I will get to them.
[17:56.920 --> 17:58.520]  But just bear with me a second.
[17:58.800 --> 17:59.980]  Let's talk about static cliques.
[18:01.320 --> 18:02.840]  Here's what's going to happen in these cliques.
[18:03.440 --> 18:07.200]  The member nodes are going to talk to their leader nodes first.
[18:07.920 --> 18:12.360]  Anytime they have a message bound for someone not in the clique, they send it to the leader node.
[18:13.800 --> 18:17.640]  And anytime they receive a message from outside the clique, they get it from the leader node.
[18:18.020 --> 18:20.400]  So interface for the cliques are just the leader nodes.
[18:22.100 --> 18:24.460]  The leader nodes are actually doing all the message passing.
[18:25.040 --> 18:29.240]  They do all the message routing on behalf of the messages they got from their members.
[18:29.560 --> 18:33.440]  And they communicate with the other leader nodes to evaluate the actual mesh network.
[18:34.340 --> 18:40.120]  And there's actually an improvement here, you can see, because we're going to reduce the number of packets that actually have to go through the network.
[18:40.620 --> 18:44.140]  These leader nodes are going to collect all the relevant traffic to route it around.
[18:45.820 --> 18:50.380]  But, and that's a good thing, you know, we want to reduce network traffic because we've already established in the mesh network.
[18:50.600 --> 18:52.300]  We don't have a lot of bandwidth.
[18:53.500 --> 18:56.920]  Now the big drawback is what happens if someone leaves the clique, right?
[18:57.160 --> 18:59.400]  We're talking about a protest here, right?
[19:00.680 --> 19:05.780]  It could be like a mass, like tear gas or something, people escaping from an area.
[19:05.940 --> 19:10.400]  Like you can't be near your clique all the time, especially if we're talking about safety, right?
[19:10.700 --> 19:16.780]  And the system even goes worse if the leader node goes down, because then the entire clique can't communicate, right?
[19:16.980 --> 19:20.360]  So this is a big drawback of this routing-style approach.
[19:20.560 --> 19:21.820]  It doesn't have as great resiliency.
[19:23.680 --> 19:26.140]  So how do we attempt to solve this?
[19:26.580 --> 19:29.660]  Well, we need to introduce some notion of dynamism.
[19:30.120 --> 19:32.200]  We need to take the static and make it dynamic.
[19:33.600 --> 19:38.600]  So we're going to talk about our second proposal, which is location-based clique routing.
[19:39.420 --> 19:46.980]  And in location-based clique routing, we're going to take a region of space, and we're going to divide it into a grid.
[19:47.760 --> 19:50.860]  In real life, we have latitude and longitude, right?
[19:51.720 --> 19:55.420]  And in our simulations, we can define like areas of 10 by 10 meters.
[19:55.960 --> 20:00.280]  But we have like an actual world grid that we can operate over, right?
[20:00.280 --> 20:05.360]  And each of these grid operations can define in a specific area.
[20:05.440 --> 20:06.960]  And the colors aren't showing so great.
[20:07.080 --> 20:10.500]  But you can say like over here, this part of the grid is a clique.
[20:11.280 --> 20:13.720]  And say that these two nodes are one clique.
[20:14.840 --> 20:20.560]  And everyone knows their location under assumption that we all have access to GPS satellites, which I know is not always an assumption, whatever.
[20:21.200 --> 20:25.760]  If we have access to the sky, we can reach some kind of satellite that tells us our location.
[20:26.400 --> 20:29.620]  And that location information basically assigns us to a clique.
[20:30.320 --> 20:31.480]  So now we have a clique of two.
[20:33.100 --> 20:36.900]  So now we've assigned everyone to cliques, but we haven't assigned leaders yet.
[20:38.300 --> 20:39.820]  So we need clique leaders.
[20:42.080 --> 20:43.660]  And we're going to elect them.
[20:43.840 --> 20:45.180]  And we're not going to do like...
[20:45.180 --> 20:47.720]  We're going to do a voting protocol, as they're called.
[20:48.020 --> 20:49.700]  This is not like voting for government.
[20:49.900 --> 20:51.000]  So the protocol is a little...
[20:51.000 --> 20:53.880]  I mean, if you're experienced with voting protocols, you might see this a little dumb.
[20:53.880 --> 20:57.120]  But this is really just to select someone to operate on our behalf.
[20:57.440 --> 20:59.340]  It's not actually to, like, run the government, right?
[21:00.220 --> 21:02.800]  So what we're going to do is we're going to divide time into epochs.
[21:02.980 --> 21:03.920]  Let's say, like, five minutes.
[21:04.220 --> 21:09.320]  And let's say for the first, like, minute-ish, we run this leader election protocol where we pick the clique leader.
[21:09.820 --> 21:15.120]  And in the remaining four minutes, we do message exchanges where we actually, like, communicate with everyone.
[21:16.220 --> 21:17.700]  So how do we do this leader election?
[21:18.160 --> 21:22.240]  It's its own, like, field of computer science, like consensus protocols and stuff like that.
[21:22.240 --> 21:23.440]  I'm not an expert in it.
[21:23.580 --> 21:26.480]  But let's just go with a toy example just for now.
[21:28.400 --> 21:31.540]  So everyone is going to wait for their turn to broadcast at some point.
[21:32.700 --> 21:37.660]  And once they have their turn, they're going to send some broadcast message with the following information.
[21:38.220 --> 21:41.140]  They're going to say their, like, cell in the script, their zone.
[21:41.700 --> 21:42.840]  And they'll say, hey, pick me.
[21:43.360 --> 21:45.060]  My identifier is two.
[21:45.480 --> 21:47.320]  And they're going to add some randomness.
[21:48.040 --> 21:51.960]  And then this randomness will be potentially different for everyone.
[21:52.140 --> 21:55.760]  And everyone in this area, in this zone, is going to broadcast this message.
[21:56.340 --> 21:59.020]  At the end, we're going to collect all of these together.
[21:59.680 --> 22:06.780]  Every node is going to collect all of the ones it's decided on and use some kind of distributed randomness protocol to identify the leader.
[22:07.460 --> 22:10.260]  And again, this is its own thing, its own area of research.
[22:10.660 --> 22:15.200]  Just trust me, bro, that we have an access to some kind of distributed randomness beacon.
[22:15.540 --> 22:15.960]  Okay?
[22:17.440 --> 22:23.020]  So, once we have the leader election, though, right, the clique thing just comes back into place.
[22:23.200 --> 22:24.560]  It cliques into place.
[22:25.920 --> 22:30.640]  So, the leader node stores all of the members that it just talked to.
[22:30.900 --> 22:33.400]  And the member nodes just need to store the leader's information.
[22:34.120 --> 22:37.580]  And then everything just is the same as with static cliques.
[22:38.140 --> 22:40.320]  Clique members send messages to clique leaders.
[22:40.660 --> 22:43.180]  All the clique leaders do their clique leader thing.
[22:44.040 --> 22:47.680]  And clique leaders send messages back to clique members that are addressed to them.
[22:50.420 --> 22:52.260]  So, we have achieved better... yeah.
[22:53.580 --> 22:54.220]  Oh, really?
[22:56.340 --> 22:56.780]  When?
[22:56.780 --> 22:57.220]  Did...
[22:57.220 --> 22:58.040]  Just now?
[23:01.080 --> 23:01.940]  Last 10 seconds.
[23:01.940 --> 23:02.120]  Last 10 seconds.
[23:02.340 --> 23:02.540]  Okay.
[23:04.240 --> 23:04.740]  All right.
[23:04.840 --> 23:05.180]  Is this better?
[23:05.320 --> 23:05.380]  No.
[23:05.520 --> 23:05.660]  Okay.
[23:05.840 --> 23:06.520]  I'm just going to yell.
[23:06.640 --> 23:06.960]  Is this good?
[23:10.240 --> 23:11.040]  Is this better?
[23:11.280 --> 23:11.480]  Okay.
[23:13.800 --> 23:14.240]  Hello?
[23:14.600 --> 23:14.860]  Okay.
[23:17.790 --> 23:18.310]  Hello?
[23:19.030 --> 23:19.690]  All right.
[23:19.910 --> 23:21.010]  So, I'm going to yell.
[23:21.890 --> 23:23.210]  This is my teacher voice.
[23:23.930 --> 23:24.570]  All right.
[23:24.950 --> 23:30.130]  So, once we've selected our leader, all the leaders...
[23:30.130 --> 23:30.710]  You missed my pun.
[23:31.230 --> 23:32.730]  Everything cliques into place.
[23:34.030 --> 23:38.710]  And our leader nodes have to store all the member nodes' information.
[23:40.150 --> 23:43.290]  And our member nodes just has to store information on the leader node.
[23:44.150 --> 23:48.670]  And once we have this information, we just operate the same as static cliques.
[23:49.530 --> 23:52.190]  All of the clique members send messages to clique leaders.
[23:52.630 --> 23:55.650]  All of the clique leaders exchange messages with each other.
[23:56.050 --> 23:58.570]  All of the clique leaders send messages back to the members.
[23:58.570 --> 24:08.170]  So this whole thing has better network overhead, better latency than our flooding-based approach, but we still encounter problems with message delivery and resiliency, right?
[24:08.270 --> 24:09.990]  We haven't necessarily solved the problem.
[24:09.990 --> 24:12.170]  What happens if someone goes offline?
[24:12.170 --> 24:13.670]  We still lose connectivity.
[24:13.870 --> 24:17.850]  But we hypothesize that it's okay because we're an epic-based system.
[24:18.230 --> 24:20.490]  Every, like, five minutes, we're going to try again.
[24:20.490 --> 24:26.150]  And maybe that's enough to still communicate even if we can't flood the network all the time.
[24:27.110 --> 24:29.030]  So that is our routing protocol.
[24:29.230 --> 24:30.250]  That is our routing setup.
[24:31.130 --> 24:31.710]  All right.
[24:31.790 --> 24:34.450]  So we're going to move up the chain here and go to the session layer.
[24:34.630 --> 24:35.590]  Talk about key agreement.
[24:36.150 --> 24:41.150]  So how do nodes create the infrastructure required for application-level communication?
[24:42.570 --> 24:46.250]  So in this instance, we're going to start talking about crypto.
[24:46.330 --> 24:48.330]  And I'm not talking about cryptocurrency.
[24:48.690 --> 24:50.090]  I'm talking about cryptography.
[24:50.090 --> 24:56.090]  So when we're talking about cryptography, we have protocols to hide information, right?
[24:57.010 --> 25:03.630]  We have ways for keys to be used to encrypt some message using an encryption algorithm like AES.
[25:04.110 --> 25:10.090]  So if two people want to communicate and they've never talked to each other before, they can encounter a key exchange protocol.
[25:11.010 --> 25:17.710]  So, for example, here in the Diffie-Holliman key exchange, Alice and Bob generate some private keys.
[25:17.990 --> 25:21.230]  And they also have public keys associated with those private keys.
[25:21.750 --> 25:33.690]  They exchange the public keys over the public Internet or public network and are able to come to a shared secret based on the mathematical properties of the public key and the private key.
[25:35.130 --> 25:40.110]  So, with that in mind, we have a way for two people to securely communicate.
[25:40.590 --> 25:42.650]  But what about groups, right?
[25:42.870 --> 25:46.010]  When we're talking about groups, it becomes a little bit more unclear.
[25:47.430 --> 25:48.730]  So we want a group key.
[25:48.870 --> 25:51.990]  We want Alice and Bob and Charlie and David to all come to the same key.
[25:53.370 --> 25:59.510]  So we could do something like this, where we do pairwise key generation with everyone.
[25:59.510 --> 26:02.930]  Each person commutes a key exchange with everyone else.
[26:03.410 --> 26:04.910]  And this does work.
[26:05.170 --> 26:08.790]  This is actually how a lot of encrypted messaging systems do groups.
[26:09.550 --> 26:12.730]  So, but the problem is this works for a centralized infrastructure.
[26:13.470 --> 26:16.610]  And centralized infrastructure is robust even for lots of members.
[26:16.850 --> 26:21.390]  But if you can imagine you have a huge group, or not even a huge group, just a few more people.
[26:21.750 --> 26:23.610]  This becomes more complex, right?
[26:23.830 --> 26:26.470]  It's quadratic in the number of messages on the network.
[26:26.470 --> 26:29.930]  And in the mesh network, we need to reduce this complexity.
[26:31.030 --> 26:35.270]  So we need an alternative solution that provides us less than n-squared messages.
[26:36.930 --> 26:41.090]  In addition, we need to support important key operations on the group.
[26:41.430 --> 26:44.150]  We need to be able to remove a node and add a node.
[26:44.730 --> 26:47.110]  Why am I talking about removing a node first?
[26:47.590 --> 26:50.930]  Because we're in the protest setting, a group member could be compromised.
[26:52.330 --> 26:53.690]  So what do I mean by compromise?
[26:53.690 --> 26:58.770]  It could be that someone in your group gets arrested and their phone gets taken and scanned by the police.
[26:58.930 --> 27:00.530]  This is something that actually happens.
[27:01.030 --> 27:06.410]  It could also be the case that Bob is actually a cop and has been infiltrating your group the whole time.
[27:06.730 --> 27:09.410]  This is also something that actually happens, right?
[27:09.970 --> 27:13.230]  So we want to remove someone from the group for whatever reason.
[27:13.470 --> 27:20.110]  We won't be able for Alice, Charlie, and David to continue operating on the group regardless of Bob.
[27:20.110 --> 27:22.550]  Basically, Bob doesn't know that he's been kicked out.
[27:24.550 --> 27:26.850]  And we also, of course, want to add people, right?
[27:26.950 --> 27:28.470]  Maybe we find Amy, Amy's pool.
[27:28.670 --> 27:29.590]  We want to add her to the group.
[27:30.410 --> 27:34.770]  But the issue is we can't just give Amy our original key, right?
[27:34.830 --> 27:40.430]  Because then Amy sees all of the previous messages, and maybe David has said some not-so-nice things that he regrets.
[27:41.570 --> 27:45.370]  So we want to be able to remove and add a node efficiently and quickly.
[27:46.330 --> 27:47.890]  And we want some security properties.
[27:47.890 --> 27:54.570]  So if you've worked in this space, you recognize some terms, confidentiality, integrity, forward secrecy, post-compromised security.
[27:54.810 --> 28:00.750]  It's okay if you don't get them, but you just kind of frame them in the sense of, well, how do we securely do these two things?
[28:01.970 --> 28:08.630]  So to solve this problem, we're going to have to figure out a way to do this without some central coordinating server.
[28:08.630 --> 28:11.110]  However, we don't have group coordination.
[28:11.790 --> 28:14.290]  And we also don't have concurrency.
[28:14.650 --> 28:17.250]  Like concurrency means everyone can operate in order.
[28:18.290 --> 28:20.650]  Because it's not feasible in a mesh network.
[28:20.850 --> 28:24.310]  So say Alice will message first, then Bob, then Charlie, then David.
[28:24.930 --> 28:28.210]  So we need a different protocol for this.
[28:28.910 --> 28:31.310]  And to do this, we're going to pull from TreeCam.
[28:31.670 --> 28:33.090]  And some of you may have heard of TreeCam.
[28:33.090 --> 28:36.590]  It's used in the messaging layer security standard by the IETF.
[28:37.230 --> 28:39.290]  And the core of TreeCam is the tree.
[28:39.750 --> 28:41.730]  Everyone is a leaf in a binary tree.
[28:42.230 --> 28:47.430]  Each pair of people have a path secret, some numerical value associated with that pair.
[28:47.830 --> 28:52.770]  Each pair of path secrets also has another path secret, all the way up to the root of the tree.
[28:53.170 --> 28:57.910]  The root of the tree is used to generate the actual key that this group uses for communication.
[28:57.910 --> 28:58.850]  Okay?
[28:59.610 --> 29:03.390]  So the question is, how does this actually help us in a mesh network?
[29:04.430 --> 29:07.070]  So an easy example is when we want to add a node.
[29:07.250 --> 29:08.950]  Let's say Hannah's cool, we want to add Hannah.
[29:09.770 --> 29:11.290]  Hannah's going to be added by George.
[29:11.610 --> 29:13.530]  So what has to change in this tree?
[29:13.610 --> 29:16.370]  I talked about we can't just reuse the same things necessarily.
[29:17.950 --> 29:21.790]  We're going to change these three parts of the tree.
[29:22.110 --> 29:24.850]  Basically everything in Hannah's path up to the root.
[29:24.850 --> 29:29.350]  So that Hannah has access to all of these things and can communicate with the group.
[29:30.830 --> 29:37.490]  So what George is going to do is George is going to take Hannah's key material and update this whole tree and tell the rest of the group.
[29:38.290 --> 29:39.990]  What does the less of the group need to know?
[29:40.410 --> 29:41.050]  Oh, it's back.
[29:41.190 --> 29:41.490]  Are we back?
[29:41.670 --> 29:42.010]  No, we're off.
[29:44.210 --> 29:47.350]  The Alice, Bob, Charlie, and David need to know the new root secret.
[29:49.730 --> 29:54.710]  I should say Emily and Fred need the root secret, as well as this intermediate path secret.
[29:55.690 --> 29:56.210]  No.
[29:57.750 --> 29:58.270]  Okay.
[29:58.930 --> 30:05.530]  And then George and, excuse me, Hannah needs this thing over here, which is the secret bit that George and her share.
[30:06.170 --> 30:08.070]  You can see there's three messages, basically.
[30:08.390 --> 30:13.070]  One addressed to these four, one addressed to these two, and one addressed to her.
[30:13.070 --> 30:18.910]  Now, the message sizes are different, but the number of messages is now logarithmic in the size of the group.
[30:19.070 --> 30:24.170]  It's not linear or quadratic, which is automatic improvement over existing systems.
[30:24.330 --> 30:24.970]  Oh, we are so back.
[30:25.490 --> 30:25.930]  All right.
[30:28.450 --> 30:33.970]  So, what we're going to do is we're going to say, well, this is definitely better than any of this, right?
[30:33.970 --> 30:41.570]  This is definitely better than a system where Alice, Bob, Charlie, David, Emily, Fred, George, Hannah all have to compute this key exchange several times.
[30:42.970 --> 30:49.810]  So, since we have this logarithmic thing, we've now achieved a more efficient system that we can use for key exchange on the mesh network.
[30:51.250 --> 30:51.750]  All right.
[30:51.970 --> 30:54.210]  So, that was our crypto and session layer.
[30:54.510 --> 30:56.690]  Now, just a brief dip into the application layer.
[30:56.870 --> 30:59.310]  What does it actually look like from the API side?
[30:59.570 --> 31:01.450]  What messaging implementation do we use?
[31:01.450 --> 31:02.690]  It's very simple.
[31:02.990 --> 31:08.390]  A message contains an ID, a time to live, a sender, a recipient, and some content.
[31:09.930 --> 31:14.090]  And, you know, we can support groups, as I've been talking about, like, incessantly this whole time.
[31:14.370 --> 31:18.250]  But we can also support pairwise communication in, like, a group of size two.
[31:19.850 --> 31:22.190]  So, now let me get to the evaluation.
[31:22.490 --> 31:27.370]  And this is, like, the big reason why I'm giving this talk here in the first place and board you with a bunch of formulas and algorithms.
[31:28.110 --> 31:32.610]  Because we're researchers, we're, you know, activist-minded, but we're not activists.
[31:32.850 --> 31:34.450]  A lot of you are actually activists.
[31:34.670 --> 31:38.330]  And probably have some insight into how these protests work.
[31:38.730 --> 31:42.730]  And we definitely want to talk to you to see if any of our models actually make sense.
[31:43.910 --> 31:46.370]  So, let me talk to you about our models.
[31:46.670 --> 31:49.670]  So, first, let's talk about our routing technology, how we're modeling that.
[31:50.150 --> 31:52.130]  We're going to use something called NS3.
[31:52.430 --> 31:55.170]  NS3 is a network simulator that some of you may be familiar with.
[31:55.170 --> 31:56.850]  Why do we use a simulation?
[31:57.150 --> 31:59.770]  It's because the NSF does not fund us to go do protests.
[32:00.950 --> 32:06.170]  So, we need to have mobility models and traffic models for our simulation.
[32:06.430 --> 32:09.590]  A mobility model is, where do people move in a protest?
[32:09.970 --> 32:13.010]  A traffic model is, what messages do they send?
[32:14.190 --> 32:19.790]  So, prior work either assumes that there's no mobility in the network, or they use data from, like, a normal Tuesday.
[32:20.150 --> 32:21.270]  And this is insufficient.
[32:22.010 --> 32:25.250]  Mobility models actually matter to the evaluation of the system.
[32:25.650 --> 32:28.870]  So, think about a protest that looks like this versus one that looks like this.
[32:29.070 --> 32:30.810]  It's a little sadder, but they still need messaging, too.
[32:31.710 --> 32:37.570]  And the mobility model will actually impact how the data is sent in this one versus this one.
[32:38.830 --> 32:40.910]  So, we want a real-world mobility model.
[32:41.010 --> 32:42.330]  And I talked about this previously.
[32:43.110 --> 32:44.690]  And, again, we can't start a protest.
[32:44.690 --> 32:50.930]  We also can't follow an existing protest, because you can't exactly tell when injustices happen, except they happen all the time.
[32:51.510 --> 32:56.050]  But also, you can't actually work and collect data from protestors.
[32:56.150 --> 32:57.270]  That'd be a huge ethical breach.
[32:57.450 --> 33:01.030]  We already know protest data is valuable to governments, right?
[33:01.110 --> 33:03.270]  We don't want to create a repository of protestor data.
[33:03.730 --> 33:08.610]  So, with that in mind, we actually use the experiences of prior protestors.
[33:08.610 --> 33:15.030]  So, the 2019 Hong Kong ELI protestors created basically a manual, which listed the things they did.
[33:15.490 --> 33:16.710]  How they did them.
[33:17.210 --> 33:19.950]  And we use that to build our mobility models.
[33:20.270 --> 33:25.870]  So, in our evaluation, we plan to evaluate a static mobility model, where everyone's just, like, standing around.
[33:26.290 --> 33:30.710]  But also, the random waypoint model, which is a common one in networking, which I'll talk about later.
[33:31.270 --> 33:36.150]  And four new models that are derived from this Hong Kong protest menu.
[33:38.210 --> 33:41.050]  So, the random waypoint model is pretty simple.
[33:41.210 --> 33:48.290]  This is a standard one in computer networking and mobile ad hoc networking, which is people just, like, the nodes just move in, like, randomly assigned directions.
[33:49.450 --> 33:51.410]  Kind of like a subway station.
[33:52.010 --> 33:56.330]  And this is a useful one because this is what basically everyone uses.
[33:56.490 --> 34:00.970]  It's a point of comparison, not necessarily an effective tool in a large-scale protest.
[34:01.290 --> 34:03.130]  But it's a point of comparison that's important.
[34:03.310 --> 34:04.210]  And again, we're academics.
[34:04.210 --> 34:05.350]  We've got to compare to fireworks.
[34:06.210 --> 34:07.390]  Let's talk about the new stuff.
[34:07.870 --> 34:17.550]  So, in the Hong Kong protest manual, they talk about large gatherings with specific purpose, such as communal art or maybe some music performance.
[34:18.090 --> 34:23.610]  And usually, you know, we're going to evaluate this as, like, basically a bunch of people standing around with a little bit of movement.
[34:23.810 --> 34:26.790]  Not, like, totally random movement all the time, but a little bit.
[34:26.890 --> 34:31.930]  If you're at a concert, like a music festival, you're probably going to stand around for a little bit, and then move to somewhere else later.
[34:32.290 --> 34:36.390]  And this kind of reflects what we saw from newsreel footage of these types of gatherings.
[34:38.590 --> 34:41.430]  Next, we'll talk about marches.
[34:41.610 --> 34:43.890]  And this is a pretty, like, intuitive one.
[34:43.990 --> 34:45.410]  This is one we're probably the most used to.
[34:45.630 --> 34:46.870]  There's a crowded city block.
[34:46.870 --> 34:50.350]  All the nodes in the network are moving in a straight line.
[34:50.950 --> 34:53.070]  Like, through some grid wall.
[34:54.870 --> 34:55.910]  That's pretty straightforward.
[34:56.790 --> 34:57.830]  Let me get past this one.
[34:58.290 --> 34:58.530]  Okay.
[34:59.170 --> 35:11.550]  And this is the blockade, which I think was a little bit more of a unique one, which I had not thought about until I read this manual, where, basically, people want to stop the police forces from coming in to a place, so they basically resupply some kind of front line.
[35:12.250 --> 35:15.770]  And here, in this example, you know, they're trying to blockade the police from entering some zone.
[35:15.770 --> 35:19.810]  They're building a bunch of blockades with whatever they can find, with people, with things.
[35:20.090 --> 35:24.710]  And there's this resupply going to the front line that reflects this blockade.
[35:26.390 --> 35:28.750]  And finally, there is the human chain.
[35:29.310 --> 35:29.790]  Yes.
[35:30.390 --> 35:33.090]  The human chain, which is basically a supply line.
[35:33.570 --> 35:38.290]  People are just passing things from arm's length to each other to resupply some front line protests.
[35:38.770 --> 35:41.830]  We define some line here interpolated by some points.
[35:42.390 --> 35:46.350]  There's not a lot of movement in this because, you know, you're handing things back and forth.
[35:46.530 --> 35:47.190]  You're kind of stationary.
[35:48.110 --> 35:50.130]  But this would be a part of a larger protest.
[35:50.870 --> 35:54.190]  With that in mind, we actually build, like, a big combination.
[35:54.670 --> 36:00.490]  Because we have these different models, we're actually able to simulate all of this in one giant city area, right?
[36:00.570 --> 36:04.350]  Like a march is happening, some gathering, a chain that's helping the blockade.
[36:04.710 --> 36:06.490]  All of these things are happening at once.
[36:06.610 --> 36:10.570]  A real-world protest, all of these things are happening at once, right?
[36:10.570 --> 36:14.970]  And this represents a really great effort by all the student collaborators to implement and evaluate this thing.
[36:15.210 --> 36:16.310]  So hats off to that.
[36:17.570 --> 36:18.050]  All right.
[36:18.330 --> 36:20.050]  So that's the mobility models.
[36:20.390 --> 36:22.550]  What about the traffic models?
[36:22.790 --> 36:24.510]  What are the messages that we are sending?
[36:26.410 --> 36:31.370]  So, previous work either uses non-protest data, or they send messages at intervals.
[36:31.770 --> 36:34.530]  And they don't really talk about things like packet size.
[36:34.530 --> 36:41.710]  There are other attributes to messaging that are just more detailed and potentially dependent or impactful in a mesh network.
[36:42.430 --> 36:43.290]  So here's an example, right?
[36:43.650 --> 36:47.830]  Sending four one-byte messages versus sending one four-byte message, right?
[36:48.250 --> 36:51.870]  Mathematically, the amount of data you're sending is the same, right?
[36:52.290 --> 37:03.170]  But to a mesh message network, this requires more work than this, because you are using more of the network to send that information, more of the available slots for broadcasting.
[37:03.710 --> 37:04.610]  And this matters.
[37:05.330 --> 37:07.730]  So we need to evaluate in this way as well.
[37:07.950 --> 37:10.710]  We need to be representative of a large-scale protest use case.
[37:11.370 --> 37:12.530]  So how do we do this?
[37:13.410 --> 37:14.550]  Well, let's think about it.
[37:14.670 --> 37:15.630]  What do we care about?
[37:15.850 --> 37:21.450]  We care about who messages are sent between, when they are sent, and what size the messages are.
[37:22.810 --> 37:26.430]  So we're going to assign nodes to group chats, because we're talking about groups.
[37:26.710 --> 37:28.650]  There are about, you know, 25 members.
[37:29.590 --> 37:33.010]  That's directly from that paper where they interviewed the ELAP protesters, right?
[37:34.110 --> 37:36.830]  And we assume that members are geographically close to each other.
[37:37.070 --> 37:47.770]  Now, this assumption may or may not hold, but we're going to simulate the fact that it doesn't hold entirely by saying a few of them are away from the group in the space.
[37:47.770 --> 37:50.690]  So we can test, like, things like partitioning and splintering.
[37:51.530 --> 37:54.290]  And we assume that a node communicates only with its group chat.
[37:54.490 --> 37:57.350]  Now, if you're in multiple groups, like, that's not the case, right?
[37:57.470 --> 38:02.410]  But you could simulate having, like, multiple nodes in a single location, talking with the group.
[38:02.810 --> 38:10.870]  But just for a clear picture, we're working on communicating with one group chat, because this is exactly what the Hong Kong protesters told the other researchers.
[38:12.310 --> 38:17.030]  So we want to compare to Perry et al., who do this regular interval sending.
[38:17.210 --> 38:18.550]  So we're going to send it every interval.
[38:19.310 --> 38:23.770]  But we also want to see something that's more representative of the large scale protest use case.
[38:24.310 --> 38:28.510]  And what we're going to do is we're going to say, we're going to send more messages during times of change.
[38:29.590 --> 38:33.830]  When something happens in the protest, you are probably moving, right?
[38:33.830 --> 38:34.990]  You are moving quickly.
[38:35.270 --> 38:37.350]  Maybe you're moving faster or slower, right?
[38:37.410 --> 38:38.810]  Because something has changed.
[38:39.130 --> 38:47.690]  So during these times of change, like maybe police are invading an area or you have to, like, help someone who's fallen down, maybe you're more likely to send a message.
[38:48.530 --> 38:55.330]  And with that intuition, we're going to increase the intervals we are sending on during these times of acceleration or deceleration.
[38:55.690 --> 38:57.930]  And this data you can get from, like, a phone, right?
[38:58.130 --> 39:01.110]  But we're simulating it in our, like, two-dimensional space.
[39:02.590 --> 39:04.250]  And then what size are these messages?
[39:04.590 --> 39:05.510]  We have a tweet.
[39:05.870 --> 39:07.390]  I guess they're called posts now.
[39:08.390 --> 39:09.990]  There are 250 bytes, right?
[39:10.290 --> 39:11.510]  Which is about, like, a text message.
[39:11.650 --> 39:12.450]  Think about a text message.
[39:12.930 --> 39:16.350]  Then a 30-second audio recording, because sometimes it's too slow to type.
[39:16.750 --> 39:17.610]  About 300 KB.
[39:18.050 --> 39:20.030]  And then a photo, because it tells thousand words.
[39:20.570 --> 39:23.410]  So those are our message sizes that we're going to evaluate on.
[39:24.470 --> 39:26.450]  And the key management is our last bit here.
[39:27.110 --> 39:31.310]  So in key management, we want to test these crypto operations just, like, to make sure that they work.
[39:31.630 --> 39:33.490]  You know, adding first people, removing people.
[39:33.950 --> 39:36.370]  Refreshing any keys that are communicating on.
[39:36.530 --> 39:38.630]  And then the whole encryption and decryption process.
[39:39.230 --> 39:41.390]  And the features we want to implement or evaluate.
[39:41.730 --> 39:44.490]  Time, ciphertext size, because that obviously matters.
[39:45.270 --> 39:47.270]  Messages required, and energy consumption.
[39:47.670 --> 39:51.970]  And energy consumption is particularly important because we're talking about smartphones, right?
[39:52.190 --> 39:55.290]  We don't want people to go protest and their phones die, right?
[39:55.470 --> 39:59.210]  We want to be able to support all of these things with limited energy consumption.
[39:59.730 --> 40:02.610]  And we have different group sizes, 20, 50, 100, 200.
[40:02.930 --> 40:05.390]  We have a couple lower ones that we're adding and working on right now.
[40:05.590 --> 40:09.050]  But this is the general, like, framework of our crypto benchmarks.
[40:09.510 --> 40:13.090]  The crypto benchmarks and the routing benchmarks can be combined, of course.
[40:13.630 --> 40:14.530]  Basically can simulate.
[40:14.890 --> 40:21.330]  We're going to add someone to the group and then use that timing information to check the network and see how that would work.
[40:21.470 --> 40:24.050]  But we're going to get to that later in our evaluation.
[40:25.510 --> 40:26.150]  Okay.
[40:26.590 --> 40:27.350]  So, summary.
[40:27.750 --> 40:34.830]  We have Amigo, which is our anonymous mesh networking communication system that we're ongoing building for large-scale protests.
[40:35.170 --> 40:39.950]  And we do things like novel routing protocols to limit the need for things like flooding.
[40:40.630 --> 40:46.770]  And we also do cryptographic techniques to match the communications patterns designed by protestors.
[40:47.090 --> 40:51.370]  And we also have realistic mobility models derived from the experiences of prior protests.
[40:51.370 --> 40:57.790]  And we hope that it will help us identify information in past work, in our work, but also future work.
[40:58.090 --> 41:01.830]  Because we've worked really hard to make sure our results are reusable and reproducible.
[41:02.390 --> 41:07.750]  And, you know, once we're wrapped up, we're going to post all of this on GitHub and people can take a look at it and see what they think.
[41:08.770 --> 41:11.850]  So, I want to reiterate that I definitely want to hear from y'all.
[41:11.850 --> 41:14.530]  If you have a point or just like your...
[41:14.530 --> 41:16.710]  that whole presentation sucked, I'm going to be outside.
[41:16.850 --> 41:17.590]  You can yell at me.
[41:18.390 --> 41:19.070]  I'm Instashar.
[41:19.230 --> 41:19.850]  Here's my email.
[41:20.010 --> 41:20.690]  Check out my website.
[41:20.830 --> 41:22.130]  Follow me on the app formerly known as Twitter.
[41:22.670 --> 41:23.210]  Thanks for listening.
[41:23.390 --> 41:24.630]  And if we have time, I'll take some questions.
[41:40.570 --> 41:41.010]  Okay.
[41:41.170 --> 41:45.050]  My question is, we do a lot of assessments of wireless technology.
[41:46.010 --> 41:51.650]  So, you know, obviously you're using the protocol and a lot of people sort of understand that spectrum.
[41:52.250 --> 41:58.630]  So, what about RDFGEN, as well as when you're in a big group, right, when you're seeing auditory engines, for example.
[41:59.070 --> 42:03.450]  You can get sales signal out, but you're also hearing a large anomalous cluster of traffic.
[42:03.450 --> 42:14.390]  So, if someone has a DSM track for analyzing, or you do something like, you know, something beyond that PC limit, et cetera, the RF jam, how is that being done?
[42:14.910 --> 42:15.310]  Yeah.
[42:15.510 --> 42:16.610]  That's a fantastic question.
[42:16.790 --> 42:18.510]  And my answer is, we don't have an answer to that.
[42:18.790 --> 42:20.370]  Because that's like a fundamentally...
[42:20.370 --> 42:20.950]  Oh, sorry.
[42:21.010 --> 42:25.690]  The question was, there are lots of ways to jam wireless things.
[42:26.050 --> 42:27.250]  Some legal, some not legal.
[42:27.470 --> 42:35.610]  And also, when you're using a protocol like this, you might create like an anomalous sensor of traffic that is different from everywhere else, and that might be able to be further analyzed.
[42:37.830 --> 42:40.590]  And my answer is, we don't have an answer to that, right?
[42:40.710 --> 42:42.390]  I mean, that's not something that we're considering.
[42:42.610 --> 42:43.810]  Again, that's... I was cheeky.
[42:43.890 --> 42:44.810]  I already talked about the link layer.
[42:44.870 --> 42:45.890]  I think they'll blow that, right?
[42:45.990 --> 42:46.390]  On purpose.
[42:46.770 --> 42:48.070]  Because we haven't thought about that.
[42:48.190 --> 42:51.250]  And I think that's a separate set of research questions that we want to think about.
[42:52.030 --> 42:54.290]  But I don't have a satisfying answer for you right now.
[42:54.410 --> 42:56.430]  But if you have some satisfying answers, I'd love to hear on the cloud.
[42:57.210 --> 42:57.450]  Yes?
[43:00.740 --> 43:05.660]  I'm curious what kind of bandwidth you're able to achieve with different sizes of the group.
[43:06.040 --> 43:11.080]  Because, like, I think, like, yeah, sending quick text messages is fine, but I think the photos are actually pretty important.
[43:11.280 --> 43:11.720]  Yes.
[43:12.040 --> 43:14.100]  Definitely something that we're thinking about.
[43:14.440 --> 43:18.660]  So the reason why I didn't have fancy charts is because we're running simulations right now.
[43:18.800 --> 43:19.900]  I thought it would be done by now.
[43:21.040 --> 43:25.260]  But actually, the fact that these simulations take really a long time to implement.
[43:26.160 --> 43:28.040]  There are huge clusters that I have control over.
[43:28.040 --> 43:31.580]  So we're trying to figure out that answer to the image question right now.
[43:32.140 --> 43:38.280]  But the bandwidth that's required for text messages is something that is feasible.
[43:38.540 --> 43:40.860]  And we can send text messages pretty reliably in a couple seconds.
[43:41.220 --> 43:45.580]  But we're still trying to understand the bandwidth for photos once that comes out of the .
[43:47.020 --> 43:47.500]  Yes?
[43:47.500 --> 43:51.780]  Have we given a lot of that application there about the application distribution?
[43:52.240 --> 43:55.900]  Because the government could just go to the app store and say, you can't distribute this application.
[43:56.380 --> 44:01.420]  And then also the application system, it becomes, it becomes hard to achieve .
[44:01.420 --> 44:04.140]  It becomes very difficult to have that tool.
[44:04.420 --> 44:08.520]  So if it's a temporary download, or side-loading, what kind of quality?
[44:08.920 --> 44:09.320]  Yeah.
[44:09.620 --> 44:10.060]  Great question.
[44:10.380 --> 44:14.320]  So, you know, this all comes back to what the protesters did in the Holocaust.
[44:15.040 --> 44:16.900]  We saw side-loading, for sure.
[44:16.900 --> 44:22.240]  People are taking, you know, they're smuggled into the apps already, and they're able to distribute it that way.
[44:22.460 --> 44:26.520]  There are also ways to distribute apps now over wireless communication channels.
[44:26.680 --> 44:28.240]  It's not available on every phone.
[44:28.720 --> 44:31.500]  Of course, Apple is only recently allowing side-loading.
[44:32.380 --> 44:36.520]  Again, that's another set of questions that I think we need to establish to try and deploy this.
[44:41.090 --> 44:47.150]  We'd have to find collaborators in the software and systems community to try to, like, actually deploy this in a reasonable way.
[44:57.190 --> 45:00.970]  So I just, I made a simple example because...
[45:02.030 --> 45:09.570]  But theoretically, as long as there's someone who is a leader node in the other zone that you can contact, you can still connect with anyone that's left.
[45:09.570 --> 45:15.370]  But of course, if that connection is broken, then you lose access to that phone.
[45:15.650 --> 45:16.570]  And that's the network partition.
[45:16.830 --> 45:19.270]  And that's something we're trying to understand in our simulation.
[45:19.530 --> 45:22.310]  That's why it shows that they think of, like, a march, a gathering.
[45:22.530 --> 45:25.730]  Can someone on the left side of that communicate with the right side?
[45:25.730 --> 45:27.370]  Is that...
[45:28.410 --> 45:33.050]  So our routing protocol should theoretically allow you to do this.
[45:33.230 --> 45:37.630]  But again, it requires someone to be on the other side that can be in range of the rest of the network.
[45:37.870 --> 45:47.490]  So there's, like, a mountain between you might not be able to do it or the tablets on the right side of that communication you should be able to do it.
[45:47.570 --> 45:55.970]  Well, my question is, for all things, how does Mesh Passage stand up to the optimal?
[45:56.830 --> 45:58.070]  So say that one more time?
[45:58.350 --> 46:02.210]  How does Mesh Passage stand up to the optimal?
[46:02.490 --> 46:25.530]  Mesh Passage be a whole source of the, for us now, five suppliers of Mesh Passage be a critical follow-up virtual that folks can have ready devices connected to YouTube computer comms and beginning to go as far as your really crazy ATAG?
[46:26.010 --> 46:29.370]  Yeah, so I'm actually a newly licensed ham myself.
[46:29.610 --> 46:31.130]  So I'm learning stuff all the time.
[46:31.290 --> 46:33.230]  I'm going to go there because I have no idea what I'm doing.
[46:33.370 --> 46:34.270]  I have my radio in there.
[46:36.350 --> 46:37.950]  So I have no idea.
[46:38.170 --> 46:45.850]  And the reason that we're starting away from the ham stuff, in fact, I'm interested in this, like in a personal level, but there are just not as many hands right now.
[46:46.110 --> 46:48.270]  As much as I wish for me to license, right?
[46:48.490 --> 46:50.050]  We need to go where people are right now.
[46:50.270 --> 46:51.570]  And that's what I'm focusing on smart stuff.
[46:52.190 --> 47:02.110]  But that being said, I'd be super interested in hearing more about this technology if it can use a second layer for those of us who have licenses who can still communicate over that.
[47:02.710 --> 47:05.950]  When you're getting lifted, do not use your ham license.
[47:07.330 --> 47:08.290]  That's good.
[47:11.510 --> 47:16.050]  I have one more question, but I'll be floating around.
[47:16.210 --> 47:16.650]  I'm fine.
[47:17.590 --> 47:20.750]  Just a question about the traffic model.
[47:20.750 --> 47:25.370]  So in certain events, let's take the police focus.
[47:26.030 --> 47:27.790]  The police, like the attack of protests.
[47:28.290 --> 47:28.990]  There's an event in traffic.
[47:30.010 --> 47:36.930]  I think the events should be split into multiple sections from the beginning of an event, and middle, and then pauses.
[47:37.270 --> 47:44.290]  Because when, let's say, the protests and the cops were working with no warning, people want to sign so necessary.
[47:44.870 --> 47:45.390]  But there will be...
[47:46.730 --> 47:47.610]  And so...
[47:49.910 --> 47:57.010]  And then when people want to find a place to hide over, then messages will be short bursts of silence.
[47:57.550 --> 47:59.150]  Further bursts in silence.
[48:00.010 --> 48:00.450]  Yeah.
[48:00.970 --> 48:02.030]  That's a good point.
[48:02.150 --> 48:02.670]  That's a good point.
[48:02.830 --> 48:03.650]  I can see the police.
[48:03.730 --> 48:04.210]  I'm not texting.
[48:04.730 --> 48:06.870]  I'm getting the heck out of Dodge first, right?
[48:07.050 --> 48:07.890]  That's a good point.
[48:08.510 --> 48:09.690]  Something that I want to think about.
[48:09.850 --> 48:11.450]  And I'll come talk a little bit more about that.
[48:11.770 --> 48:12.090]  All right.
[48:12.250 --> 48:12.650]  Thanks, y'all.
[48:12.730 --> 48:13.050]  I love you.