[00:00.000 --> 00:02.640]  I first want to say I'm really excited to be here.
[00:02.840 --> 00:12.260]  This is my third HOPE, but my first time speaking, you know, and similar to what Cory Doctorow said yesterday, like I picked up my first copy of HOPE like 15 years ago.
[00:12.360 --> 00:13.380]  So it's awesome to be here.
[00:14.740 --> 00:20.240]  As far as questions, if you have clarification questions during the talk, please feel free.
[00:20.460 --> 00:22.700]  I encourage you to ask them.
[00:23.000 --> 00:27.680]  But any longer or critique questions, you can save those for afterwards.
[00:27.680 --> 00:31.540]  Okay, so, like you said, I'm Ed Platt.
[00:31.660 --> 00:34.000]  I study networks and censorship.
[00:34.400 --> 00:41.760]  And I'll be talking about some work that I've been doing in my PhD work at the University of Michigan School of Information.
[00:42.100 --> 00:44.480]  My advisor is Daniel Romero.
[00:46.160 --> 00:51.240]  So there's a well-known quote attributed to the computer scientist John Gilmore.
[00:51.500 --> 00:57.080]  It says, the net interprets censorship as damage and routes around it.
[00:57.780 --> 01:02.460]  So this has become kind of a railing cry for free expression online.
[01:03.120 --> 01:21.460]  And more than that, it really captures the excitement that the Internet is fundamentally something new, that it's different from what's come before, and it can be a powerful tool for protecting free expression, and for exposing abuses of power, and ending those abuses of power.
[01:22.280 --> 01:23.960]  There are a lot of examples of this.
[01:24.200 --> 01:26.200]  You don't have to look far, even right now.
[01:27.280 --> 01:30.320]  Was anybody in the Courage Foundation talk this morning?
[01:31.180 --> 01:32.200]  A couple of you?
[01:32.300 --> 01:33.220]  That was really good.
[01:34.140 --> 01:36.200]  I encourage anyone to go watch it.
[01:36.920 --> 01:46.900]  A lot of times discussions of free expression can get really abstract, but these are real issues that affect real people, and I thought that talk did a great job of really digging into that.
[01:46.900 --> 01:49.080]  But I'll give one example.
[01:49.420 --> 02:02.140]  Here in the US, right now, there's a big discussion going on about police brutality, police misconduct, especially directed at minorities, particularly black Americans.
[02:03.520 --> 02:05.960]  And it's largely due to the Internet.
[02:06.560 --> 02:12.580]  The ability to take cell phone videos, to share those globally within an instant.
[02:14.580 --> 02:25.220]  Any time someone like a police officer abuses power, the institution behind them has an incentive, whether or not they decide to use that incentive.
[02:25.220 --> 02:27.860]  They have an incentive to censor that, any evidence.
[02:29.060 --> 02:35.160]  But once that evidence is on the Internet, that becomes much harder than it's ever been in history.
[02:35.820 --> 02:43.940]  So that's really one of the fundamental ideas of why the Internet can be so powerful for changing social issues.
[02:47.960 --> 02:50.100]  So, yeah, moving on.
[02:50.520 --> 02:51.880]  Back to this quote here.
[02:53.500 --> 02:55.320]  Oh, one more motivation.
[02:55.820 --> 02:57.440]  More mundane motivation.
[02:57.780 --> 03:00.220]  But much more common in all of our lives, probably.
[03:00.700 --> 03:10.200]  We have the Internet right now run by a lot of for-profit companies who are collecting user data in proprietary silos.
[03:11.020 --> 03:12.620]  And they're driven by profit.
[03:12.740 --> 03:13.960]  They're not trying to censor people.
[03:14.160 --> 03:18.220]  They're trying to sell targeted ads and doing a pretty good job of making money at it.
[03:18.780 --> 03:20.760]  But this affects a form of censorship.
[03:21.960 --> 03:29.080]  If I want to share something on Facebook, and you're not on Facebook, I can make it public, but I can't share it with you.
[03:30.360 --> 03:38.600]  So, my inability to share something on any of these proprietary platforms is a form of censorship.
[03:39.120 --> 03:49.760]  And just the fact that this data is stored in one place or under the control of one company creates a real danger of that data being censored.
[03:50.060 --> 03:53.220]  And you can also find examples of that all over the place.
[03:55.460 --> 04:01.660]  So, back to this quote, the net interprets censorship as damage and routes around it.
[04:02.340 --> 04:04.940]  I'm going to go into whether or not this is true, how true it is.
[04:05.460 --> 04:09.640]  But first, I want to dig a little deeper as to what it actually means.
[04:10.400 --> 04:14.420]  So, I see it as a statement about two things, which is why I chose it for this talk.
[04:14.820 --> 04:16.520]  One, it's a statement about networks.
[04:17.220 --> 04:24.140]  When you're talking about routing, you're talking about how people are connected to each other, how computers are connected to each other.
[04:24.580 --> 04:25.960]  I study networks.
[04:26.180 --> 04:31.080]  I think networks are really important in this topic of censorship and expression.
[04:31.560 --> 04:34.240]  So, that's one reason that I'm focusing on it.
[04:34.440 --> 04:41.360]  And the other is the idea of decentralization.
[04:41.680 --> 04:54.320]  So, if you say you can route around something, that means that there's nothing on the Internet that is so central, so important that if it's censored and removed, that you can't take it, that you can't go around it, that you can't replace it.
[04:55.340 --> 04:57.980]  So, that's really the gist of this.
[04:58.040 --> 05:04.560]  This is saying that there's nothing so important in the network of the Internet that you can't find a path around it to connect you to everything else.
[05:05.360 --> 05:10.860]  And in addition to censorship, this really generalizes to any kind of targeted attack.
[05:10.860 --> 05:14.040]  So, there's no target that's so central.
[05:14.480 --> 05:17.640]  So, let's see if this is actually true, how true it is.
[05:18.280 --> 05:19.700]  I'll give a few examples.
[05:20.400 --> 05:21.960]  One is 2008.
[05:22.480 --> 05:24.880]  Pakistan decided to censor YouTube.
[05:25.660 --> 05:32.380]  They did this by instructing all of their ISPs within the nation to censor YouTube.
[05:32.860 --> 05:39.820]  Some of them did this by advertising fake routes to YouTube in their Internet routers.
[05:40.520 --> 05:42.220]  Within the nation, this worked very well.
[05:43.380 --> 05:47.120]  Any traffic going to YouTube wound up going to those routers and just getting dropped.
[05:47.940 --> 05:50.240]  But what happened next wasn't expected.
[05:50.840 --> 05:57.660]  Routers in other countries started seeing that route, picking it up, advertising it, passing it on to other routers.
[05:58.200 --> 06:05.240]  So, there was a day where for several hours, all around the world, YouTube was down for several hours in multiple countries.
[06:05.240 --> 06:10.120]  So, in this case, the Internet definitely did not route around the censorship.
[06:11.640 --> 06:13.460]  Another interesting example.
[06:13.660 --> 06:19.340]  There were some great talks at the most recent hope about this.
[06:20.140 --> 06:30.340]  But in 2013, the secure webmail provider Lavabit received an order to turn their private SSL keys over to the FBI.
[06:30.340 --> 06:34.880]  The FBI wanted to surveil the emails going through that service.
[06:35.420 --> 06:39.100]  Well, that kind of defeats the purpose of a secure email service.
[06:39.300 --> 06:52.280]  So, the team at Lavabit tried some creative solutions to prevent that from happening, including printing the keys out in a tiny font and giving the papers to the FBI.
[06:52.800 --> 06:54.420]  But that didn't work in the long run.
[06:55.040 --> 06:56.700]  So, they shut down.
[06:57.000 --> 07:03.360]  That was their only way to comply with the order without allowing the FBI to surveil their users.
[07:04.140 --> 07:06.380]  So, it wasn't intended to be a censorship.
[07:07.280 --> 07:09.920]  But it wound up becoming censorship.
[07:11.060 --> 07:15.280]  And it's worth mentioning here that they had great crypto.
[07:15.440 --> 07:16.960]  It wasn't the crypto that failed here.
[07:18.480 --> 07:21.260]  This was legal coercion.
[07:21.260 --> 07:24.280]  This was a targeted attack, but it wasn't a technical attack.
[07:24.560 --> 07:25.540]  It was a social attack.
[07:26.620 --> 07:29.140]  So, that's kind of a theme that will come up throughout this talk.
[07:30.420 --> 07:36.280]  And the third and final example is something probably most people in this room are familiar with.
[07:36.520 --> 07:38.460]  The NSA's quantum program.
[07:38.800 --> 07:42.040]  Again, great talks on this at the most recent hope.
[07:42.040 --> 07:53.460]  But in particular, I'll talk about the Fox Acid program, which was malware installed on key Internet routers.
[07:54.280 --> 08:09.100]  So, by targeting routers that had a very central location on the Internet, the NSA was able to, with a very high probability, surveil a lot of traffic going to major Internet sites.
[08:09.100 --> 08:18.480]  So, in this case, not censorship at all, but still relying on centralization to create a targeted attack.
[08:21.060 --> 08:24.640]  So, what about the quote that I started with?
[08:24.960 --> 08:26.200]  These shouldn't work, right?
[08:26.380 --> 08:27.400]  The Internet is decentralized.
[08:28.080 --> 08:30.440]  Well, that's partially true.
[08:30.720 --> 08:33.480]  TCP, the protocol, is decentralized.
[08:34.260 --> 08:36.540]  But the Internet is more than TCP.
[08:37.520 --> 08:42.460]  You know, there are a lot of other things, a lot of other technologies going on.
[08:42.800 --> 08:45.840]  The Internet is actually more than technology.
[08:46.080 --> 08:48.820]  The Internet is also made of people.
[08:49.500 --> 08:52.340]  We're strange people, but we are still people.
[08:53.600 --> 08:56.500]  So, the Internet is a socio-technical system.
[08:56.700 --> 08:59.480]  And that's something that comes up in my research a lot.
[08:59.480 --> 09:04.680]  But if you want to talk about decentralization, you can't just look at the technology.
[09:05.520 --> 09:11.700]  The recent Ethereum hack with the DAO is a good example of this.
[09:11.860 --> 09:18.180]  I won't go into detail, but if your technology is decentralized, your whole system isn't decentralized.
[09:18.180 --> 09:27.460]  Unless the social systems around that, the decision-making, governance, everything that's implementing those technical systems, are also decentralized.
[09:27.460 --> 09:32.860]  So, I really like to be aware of that, thinking about these issues.
[09:32.960 --> 09:35.340]  And I encourage all of you to do the same in your work.
[09:36.900 --> 09:51.080]  So, if your system depends on a single physical location, if it depends on a single legal jurisdiction, if it's controlled by a single legal entity, it's really not decentralized.
[09:51.080 --> 09:59.560]  All of these things subject you, maybe not to technical attacks, but to legal coercion and other forms of targeted attacks.
[10:01.320 --> 10:03.300]  So, decentralizing these is really easy.
[10:03.420 --> 10:11.320]  You just break your system into parts, and you give them out to people in different places, under different jurisdictions, controlled by different legal entities.
[10:12.280 --> 10:17.240]  But then you need a way for all those parts to talk to each other, which is where the networking comes in.
[10:19.680 --> 10:22.140]  So, this is what I primarily study.
[10:22.280 --> 10:23.900]  This is primarily the subject of the talk.
[10:24.920 --> 10:29.640]  When you connect all those different parts to each other, you can do it in ways that are more or less centralized.
[10:30.640 --> 10:34.480]  Ways that allow that kind of routing around censorship in ways that don't.
[10:35.860 --> 10:38.020]  So, this is what I'm here to talk to you about.
[10:38.420 --> 10:39.720]  How do we actually do that?
[10:39.720 --> 10:47.240]  How do we build and design a decentralized network that is resistant to these types of censorship and targeted attacks?
[10:49.320 --> 10:57.440]  And before I try to start answering that, I just want to throw out some terminology and clarify what I mean when I say network.
[10:57.900 --> 10:59.120]  Network can mean a lot of things.
[10:59.280 --> 11:00.180]  Very overloaded word.
[11:01.420 --> 11:05.840]  In this talk, I'm using it in the network science sense, so it's very abstract.
[11:06.240 --> 11:07.180]  You have some things.
[11:07.540 --> 11:08.900]  The things could be people.
[11:09.320 --> 11:11.480]  The things could be computers.
[11:12.740 --> 11:14.440]  But we don't care what they are.
[11:14.540 --> 11:15.960]  We just care that there are things.
[11:16.320 --> 11:17.560]  So, I'll call them nodes.
[11:17.740 --> 11:18.460]  I'll call them vertices.
[11:19.340 --> 11:23.380]  If any of you are mathematicians and know graph theory, this should all be really familiar.
[11:24.220 --> 11:30.800]  And the other important thing about these things is that they have relationships with each other.
[11:31.920 --> 11:35.880]  If your things are people, the relationships could be friendships.
[11:36.400 --> 11:37.920]  They could be trust relationships.
[11:38.240 --> 11:41.900]  If they're computers, they could be wired or wireless links.
[11:42.320 --> 11:47.120]  But again, as far as network structure, we don't care about the details.
[11:47.120 --> 11:51.600]  We just care which things are in relationships with which other things.
[11:54.120 --> 12:00.620]  So, now that we have the term network defined, well, we can look at the Internet.
[12:00.780 --> 12:01.600]  The Internet is a network.
[12:01.880 --> 12:03.060]  And we can say, what is its Internet?
[12:03.340 --> 12:04.880]  What is its network structure?
[12:05.340 --> 12:11.380]  And in 2000, Albert, Zhang, and Barabashi published a paper where they did just this.
[12:11.980 --> 12:13.560]  And they found some interesting stuff.
[12:14.720 --> 12:17.160]  This is one of two graphs I'll show you.
[12:17.160 --> 12:19.960]  So, you're halfway through the math part.
[12:21.780 --> 12:29.420]  They first started by taking both a network of all the routers on the Internet that they got the data for.
[12:29.840 --> 12:32.660]  And the links on the world wide web.
[12:33.280 --> 12:39.460]  And they started by removing nodes from those networks and seeing how the networks change.
[12:40.040 --> 12:42.060]  First, they removed nodes randomly.
[12:42.760 --> 12:45.060]  That's the bottom line on both of these graphs.
[12:45.060 --> 12:47.700]  And very, very little about the network changed.
[12:48.160 --> 12:49.580]  So, that's good.
[12:49.960 --> 12:54.240]  That means that the Internet is pretty resilient against random failures.
[12:55.000 --> 13:00.320]  And that's partly where this idea of the Internet routing around damage comes from.
[13:00.320 --> 13:06.800]  But, then, they started removing the most highly connected nodes first.
[13:07.140 --> 13:08.740]  And they saw something very different.
[13:09.940 --> 13:17.780]  As soon as they began removing nodes, the distance between nodes in the network started increasing.
[13:18.180 --> 13:23.320]  The probability that any two nodes in the network would be entirely disconnected started increasing.
[13:25.440 --> 13:28.040]  Now, this doesn't mean that the world is ending right now.
[13:28.900 --> 13:32.520]  You know, here they removed 2% of the nodes on the Internet.
[13:32.860 --> 13:36.940]  And the average distance between nodes tripled.
[13:38.500 --> 13:41.840]  Which is not good, but not the end of the world.
[13:42.700 --> 13:49.760]  But still, this is very different from the idea of the Internet routing around censorship, routing around targeted attacks.
[13:51.940 --> 13:55.900]  Now, they also explained why they think this is happening.
[13:56.920 --> 14:05.620]  And it's because the Internet... the connections between Internet routers turn out to follow what's called a heavy tail distribution.
[14:06.340 --> 14:07.640]  Saw someone go for a picture.
[14:07.740 --> 14:08.360]  I'll put that back up.
[14:10.200 --> 14:12.900]  And a heavy tail distribution, very simple.
[14:12.900 --> 14:17.720]  It means there are a few nodes that have very high connection.
[14:18.360 --> 14:20.820]  And a lot of nodes that have very low connection.
[14:21.020 --> 14:22.320]  So, very high inequality.
[14:23.160 --> 14:33.480]  And you get this when you have networks where new connections tend to form to existing nodes that already have a large number of connections.
[14:33.740 --> 14:36.720]  You might still get a few that connect randomly.
[14:38.660 --> 14:41.760]  But... but... but... but... but...
[14:42.720 --> 14:48.060]  If one of my friends trusts you, I'm not as likely to trust you as if a hundred of my friends trust you.
[14:48.260 --> 14:55.640]  So, there's useful information that we might be able to take advantage of that is not contained in the Web of Trust model.
[15:00.180 --> 15:01.120]  Sorry, Web of Trust.
[15:01.340 --> 15:04.180]  You've been good to us, but we've got to move on.
[15:05.960 --> 15:12.120]  Okay, so now I'm going to talk about some of the research I've been doing over the past year or so at the University of Michigan.
[15:12.820 --> 15:14.660]  Again, with my advisor, Daniel Romero.
[15:15.560 --> 15:22.560]  And I've been working on extending and modifying the Web of Trust model in a way that lets us address some of these limitations.
[15:23.000 --> 15:27.140]  We're calling this modified model the partial trust model.
[15:27.940 --> 15:36.120]  And it starts with the assumption that you can trust everyone, friends of friends, up to a fixed number of hops away.
[15:36.360 --> 15:38.240]  You know, so in this case, two hops.
[15:40.220 --> 15:46.800]  That's still not an entirely realistic assumption, but it's at least more realistic than assuming you can do that to infinity.
[15:49.180 --> 16:00.720]  Now, the other assumption is that, you know, beyond that, there is an adversary who has the ability to compromise some fixed number of nodes.
[16:01.300 --> 16:06.240]  Adversaries usually have some limit on their resources, which is why we make this assumption.
[16:07.060 --> 16:13.780]  So, in this model, the trusted nodes around Alice, for instance, form what I call a trusted neighborhood.
[16:14.580 --> 16:19.240]  And outside of those, you have an untrusted region where the faults can occur.
[16:20.960 --> 16:29.720]  Then, connecting those, you have the nodes in the trusted neighborhood that connect to the untrusted region.
[16:30.060 --> 16:34.920]  I call those the trust boundary, and those nodes are going to play an important role.
[16:37.040 --> 16:41.100]  Now, we can simplify this, which is kind of the whole point of having a model.
[16:41.600 --> 16:44.220]  So, it's going to look progressively less scary.
[16:45.480 --> 16:48.360]  We want to simplify that middle part, especially.
[16:49.500 --> 16:54.520]  And we can use a result from network science called the max-flow-min-cut theorem.
[16:56.020 --> 17:03.580]  Say that our adversary male wants to completely cut off Alice and Bob.
[17:04.840 --> 17:15.120]  There's some bottleneck in that network that cuts through some number of nodes that is the smallest number of nodes that Mal would have to compromise.
[17:15.500 --> 17:16.860]  That's called the min-cut.
[17:17.820 --> 17:21.860]  And that's equivalent to the maximum number of...
[17:21.860 --> 17:22.580]  Sorry, the...
[17:22.580 --> 17:28.360]  Yes, the maximum number of independent paths going from Alice to Bob.
[17:28.360 --> 17:39.700]  And when I say independent path, I just mean two paths so that Mal can't compromise both of those paths by compromising a single node.
[17:40.140 --> 17:46.360]  And the reason this is important is because if...
[17:46.360 --> 17:51.400]  If Mal is smart, which we assume our adversary is, we want...
[17:51.400 --> 18:01.520]  She would want to compromise a node only if it's going to compromise one of those paths that isn't already compromised.
[18:02.520 --> 18:07.200]  So, we can actually replace all of these...
[18:07.200 --> 18:11.540]  All of this complicated network with just some number of paths with a single node.
[18:11.540 --> 18:14.800]  Because if a path is already compromised...
[18:14.800 --> 18:19.100]  Well, if you compromise one node on a path, the entire path is compromised.
[18:20.540 --> 18:23.340]  So, it doesn't make any sense for the adversary to compromise anymore.
[18:23.840 --> 18:26.620]  So, this is where a lot of the power in this model comes from.
[18:26.760 --> 18:27.780]  The ability to simplify.
[18:29.380 --> 18:43.480]  Another nice thing is if there are no bottlenecks in the untrusted region, which is true for a lot of networks and some of the ones I'll mention later, then the bottleneck winds up being the trust boundary.
[18:44.200 --> 18:51.740]  So, the number of paths is simply the size of Alice's trust boundary or Bob's trust boundary.
[18:51.740 --> 18:55.000]  Or the smaller of the two, whichever is the bottleneck.
[18:56.560 --> 18:59.040]  And we can further simplify this.
[18:59.540 --> 19:03.460]  Because really, we just care about whether the message gets through the untrusted region.
[19:04.280 --> 19:10.080]  So, now we have some number of independent channels in the untrusted region.
[19:12.180 --> 19:18.700]  And each with one node, which is equivalent to compromising the entire path that Mel can compromise.
[19:20.160 --> 19:22.360]  So, this is our partial trust model.
[19:23.800 --> 19:33.360]  And now I'd like to use this to analyze a particular type of routing algorithm and error correction and fault tolerance.
[19:35.060 --> 19:40.260]  So, it's a type of routing that's been around for a while called concurrent multipath routing.
[19:40.680 --> 19:45.920]  And the idea is simply that you send multiple copies of a message in parallel.
[19:45.920 --> 19:51.700]  It's used a lot for fault tolerance against random faults.
[19:51.880 --> 19:57.220]  But there hasn't been a lot of work applying it to targeted attacks, targeted faults.
[19:57.960 --> 20:08.640]  And one of the things we get from the partial trust model is the ability to analyze the efficacy of this scheme with targeted attacks.
[20:09.960 --> 20:17.120]  So, in this example, Alice is just choosing two of the possible paths to send a copy of a message and ignoring the third.
[20:19.400 --> 20:28.640]  Similarly, Mel chooses some of the nodes in the untrusted region, some of the paths to compromise.
[20:29.400 --> 20:35.180]  And I should mention that in this scheme, Alice's optimal strategy is actually to choose randomly.
[20:37.220 --> 20:40.120]  And Mel's optimal scheme is to choose randomly.
[20:40.360 --> 20:43.900]  So, there's really no strategy that goes on here.
[20:44.060 --> 20:45.960]  It's just entirely random.
[20:47.100 --> 20:50.020]  So, what happens on Bob's end?
[20:50.640 --> 20:53.020]  Well, you have one of two cases.
[20:53.600 --> 21:10.840]  If Bob doesn't get all of the messages, and Alice can include the number of messages she sent as part of the message, or if Bob gets some of the messages and they disagree with each other, Bob knows that something has gone wrong.
[21:11.160 --> 21:12.220]  He's detected an error.
[21:12.700 --> 21:13.480]  That's okay.
[21:13.700 --> 21:14.760]  You can always resend.
[21:14.940 --> 21:16.280]  So, that's not the end of the world.
[21:17.440 --> 21:25.200]  The other possibility is that Bob gets all of the messages and they all agree with each other.
[21:26.320 --> 21:32.560]  Now, that probably means that Bob has received the message uncompromised, which is great.
[21:32.760 --> 21:33.320]  That's what we want.
[21:34.120 --> 21:40.560]  But there's also a chance that it means that Bob has received messages that have all been compromised.
[21:40.960 --> 21:42.700]  And this is really the bad case.
[21:42.800 --> 21:43.900]  This is what we want to avoid.
[21:43.900 --> 21:46.500]  This is an undetectable error.
[21:46.840 --> 21:51.900]  Because to Bob, it looks like everything matches, everything's right.
[21:52.220 --> 21:56.420]  But Mel has successfully changed the contents of the message.
[21:57.000 --> 22:00.260]  Or blocked the message entirely so Bob doesn't see anything.
[22:02.620 --> 22:10.940]  So we can easily calculate the probability that Mel is able to do that to successfully block all of Alice's messages.
[22:11.720 --> 22:13.760]  And this is the second graph.
[22:13.940 --> 22:15.840]  So, we're done with graphs after this.
[22:16.520 --> 22:25.400]  On the x-axis, we have the fraction of the possible paths that Alice utilizes to send a message.
[22:26.000 --> 22:32.340]  On the y-axis, we have the number of paths that Mel is able to compromise.
[22:32.860 --> 22:38.200]  And then the color of the graph is the probability of an undetectable error.
[22:38.920 --> 22:41.500]  The first thing you'll notice is that most of this graph is black.
[22:41.780 --> 22:42.300]  That's good.
[22:42.720 --> 22:44.660]  Because that means low probability.
[22:45.560 --> 23:01.100]  And if you look a little closer, it's interesting because a large increase in attack power on Mel's end can be compensated by a very small increase in the number of copies sent by Alice.
[23:01.420 --> 23:07.160]  So that means that this scheme is fundamentally difficult to attack and easy to defend.
[23:07.420 --> 23:12.500]  So that's definitely a property that you want in any kind of censorship or attack resistance.
[23:13.300 --> 23:23.860]  And there's one even more interesting thing that you can't actually see in this graph, because it's just plotted for one number of possible paths, in this case 25.
[23:24.760 --> 23:32.880]  But the probability of an undetectable error decreases exponentially with the number of possible paths.
[23:33.200 --> 23:36.140]  Even if Alice only uses the same number of those.
[23:36.680 --> 23:38.800]  So, think about that for a second.
[23:38.920 --> 23:39.580]  That's really cool.
[23:39.580 --> 23:51.860]  Alice doesn't have to do any extra work but gets an exponential increase in her protection from attack just by being part of a more highly connected network.
[23:52.480 --> 23:54.300]  So this is what we're really trying to get at.
[23:54.420 --> 24:06.200]  We're trying to understand not what Alice does, not what Bob does, not what Eve or Mal does, but how the actual structure of the network can provide protection.
[24:09.400 --> 24:13.460]  Okay, so this doesn't actually tell us how to get this network.
[24:13.600 --> 24:16.020]  This just says we want a network with lots of paths.
[24:16.620 --> 24:19.780]  So let's go back to the model and try to figure out how we can do that.
[24:21.740 --> 24:30.360]  Well, we're assuming that the bottleneck is the trust boundary, which is the set of nodes that is however many hops away you trust.
[24:30.360 --> 24:31.680]  So in this case two.
[24:33.200 --> 24:39.860]  And that gives us the size of the... that gives us the min cut, that gives us the number of paths.
[24:40.100 --> 24:41.740]  So we want that to be big.
[24:41.900 --> 24:50.520]  So we want a network where as you move away from any node, you very quickly reach a larger and larger number of nodes.
[24:51.560 --> 24:54.480]  I'll just call that connectivity for the sake of this talk.
[24:55.280 --> 25:03.860]  There are lots of different slightly related terms in network science that I can totally geek out with you about offline.
[25:04.920 --> 25:06.240]  But that's our goal.
[25:06.320 --> 25:06.900]  That's what we want.
[25:08.580 --> 25:12.860]  And so I've been looking at a type of network called vertex transitive networks.
[25:13.340 --> 25:14.580]  The idea is simple.
[25:15.040 --> 25:18.820]  Every node is structurally equivalent to every other node.
[25:18.820 --> 25:21.720]  So there's no way to tell them apart.
[25:21.980 --> 25:24.940]  You know, you can think about the corners on a square.
[25:25.280 --> 25:27.360]  They're each connected to two other corners.
[25:27.700 --> 25:32.180]  And the relationships between those corners are... they're both on opposite sides.
[25:34.480 --> 25:38.500]  These networks are, in a way, the most decentralized you can get.
[25:38.840 --> 25:43.580]  If every node is equal, there's no way for anyone to be central.
[25:44.940 --> 25:48.400]  And they've been known and used a long time in parallel processing.
[25:50.480 --> 25:53.940]  Particularly because they're a very rigidly defined network.
[25:54.300 --> 25:56.500]  And in parallel processing, you can do that.
[25:56.520 --> 25:58.360]  You know, if you're building a network of processors.
[25:59.340 --> 26:03.080]  So one of the networks I've been looking at is the M-dimensional cube.
[26:03.660 --> 26:07.580]  This is just... in one dimension, it's a line.
[26:07.820 --> 26:09.200]  Two dimensions, it's a square.
[26:09.540 --> 26:10.680]  Three dimensions, it's a cube.
[26:10.680 --> 26:16.780]  And if you're a weird mathematician like me, you can just keep counting up and drawing lots of crazy pictures.
[26:17.240 --> 26:18.820]  And the math works out.
[26:19.640 --> 26:22.320]  And this is a vertex transitive network that is kind of useful.
[26:23.100 --> 26:24.560]  The other is really neat.
[26:24.860 --> 26:27.760]  I learned about this a few months ago.
[26:27.960 --> 26:32.180]  And if you're into this kind of stuff and you haven't heard of it, you should look at it.
[26:32.180 --> 26:33.900]  But it's called the butterfly.
[26:34.380 --> 26:37.760]  It's based on a hypercube or an M-dimensional cube.
[26:38.260 --> 26:41.220]  But each row corresponds to a binary number.
[26:41.540 --> 26:46.160]  Each column corresponds to an index in that binary number.
[26:47.040 --> 26:49.180]  The nodes corresponding...
[26:49.700 --> 26:53.360]  Well, the nodes in the same row are all connected in a ring.
[26:53.360 --> 26:58.580]  And nodes in different rows are connected by a bit flip.
[26:58.900 --> 27:02.120]  So they're connected if they have one bit different.
[27:02.600 --> 27:04.980]  And which bit depends on which column it's in.
[27:05.080 --> 27:06.300]  So you get this kind of neat pattern.
[27:08.520 --> 27:11.520]  So what are the connectivity properties of these?
[27:12.020 --> 27:16.660]  Well, they're both exponential in the number of hops that you trust.
[27:16.660 --> 27:17.860]  So that's pretty good.
[27:19.980 --> 27:29.300]  An even more interesting thing is that for the M-dimensional cube, the base of that exponent grows with the size of the network.
[27:29.840 --> 27:33.560]  So as the network gets bigger, your connectivity grows.
[27:34.340 --> 27:36.400]  This is also really cool.
[27:36.760 --> 27:42.660]  It means that as the network gets bigger, your ability to resist attack...
[27:43.280 --> 27:45.020]  targeted attack increases.
[27:45.720 --> 27:47.640]  So that's a really desirable property.
[27:47.920 --> 27:49.480]  This is not true of the butterfly.
[27:50.400 --> 27:54.700]  But the butterfly has a different kind of benefit and trade-off here.
[27:55.300 --> 28:05.020]  Which is that the number of connections in each node increases on the cube as the network grows.
[28:05.400 --> 28:09.200]  Whereas with the butterfly, each node is only connected...
[28:09.200 --> 28:11.340]  It's ever only connected to four other nodes.
[28:11.580 --> 28:14.640]  So the butterfly scales a lot better than the M-cube.
[28:15.280 --> 28:22.480]  But the M-cube gives you this really cool property of getting more fault-tolerant as it grows.
[28:22.900 --> 28:30.380]  And part of the research I'm doing is looking at other networks and trying to find networks that kind of give you the best of both worlds here.
[28:32.380 --> 28:37.160]  So that's kind of the end of the research that I've been doing.
[28:37.400 --> 28:38.560]  Oh, I should talk about limitations.
[28:38.900 --> 28:39.000]  Yeah.
[28:39.220 --> 28:39.920]  Yeah, that's fair.
[28:40.940 --> 28:41.360]  Yeah.
[28:41.460 --> 28:46.200]  So limitations of this, like I said, these are kind of rigidly defined networks.
[28:46.200 --> 28:47.760]  So you don't have flexible trust.
[28:48.040 --> 28:51.960]  You have to build the trust relationships in a particular pattern.
[28:52.880 --> 28:56.020]  There are use cases where that's feasible.
[28:57.980 --> 28:58.680]  Let's see.
[28:58.860 --> 29:00.540]  I have a list of limitations here.
[29:02.020 --> 29:08.880]  And the other is that, as I said before, really the Internet is a socio-technical system.
[29:09.340 --> 29:11.120]  This is just looking at structure.
[29:11.380 --> 29:16.120]  This is ignoring a lot of important stuff, like what goes on over those connections.
[29:17.140 --> 29:21.080]  So this is not the whole story, but I think it's an important part of the story.
[29:22.240 --> 29:22.680]  Okay.
[29:22.800 --> 29:28.920]  So now moving on, I just want to kind of give a shout out to some of the other technologies that are out there.
[29:30.600 --> 29:36.360]  Freenet, I only learned about it this past year, but it's been around since 1999.
[29:37.300 --> 29:40.820]  It's an anti-censorship content addressable network.
[29:41.920 --> 29:43.120]  It's been active.
[29:43.980 --> 29:45.420]  There are lots of users running nodes.
[29:46.840 --> 29:48.340]  Active developer community.
[29:48.500 --> 29:49.880]  I was in the IRC the other day.
[29:50.180 --> 29:51.280]  People are really friendly.
[29:53.400 --> 29:57.260]  They use small world routing, which is pretty cool.
[29:58.220 --> 30:08.820]  The basic idea comes from this observation that in human social networks, we tend to be connected to a lot of people who are very near us in some way.
[30:08.980 --> 30:12.240]  You know, either geographic location, something like that.
[30:12.240 --> 30:21.060]  But then we have a small number of shortcuts to maybe old college buddies or that cousin who moved to Minnesota.
[30:22.420 --> 30:27.280]  And those very quickly reduce the size of our social world.
[30:27.280 --> 30:32.340]  So if you've heard the six degrees of separation, it's really based on this kind of theorizing.
[30:32.800 --> 30:38.240]  Showing that just by adding a few of these links, you get a very highly connected, very dense network.
[30:39.000 --> 30:39.520]  So...
[30:39.520 --> 30:40.620]  Or not very dense.
[30:41.800 --> 30:45.460]  Not dense, but highly connected, which is really desirable.
[30:45.460 --> 30:51.940]  So Freenet uses the assumption that your network has this structure.
[30:52.320 --> 31:00.220]  And maps that onto the key space used by the hash table to create an efficient routing algorithm.
[31:00.480 --> 31:06.100]  Or to take advantage of an efficient routing algorithm that was published by Kleinberg.
[31:07.340 --> 31:09.060]  This is also one of the limitations.
[31:10.040 --> 31:13.820]  You know, there's an assumption that your network actually follows this property.
[31:14.260 --> 31:18.800]  And in reality, the performance depends on the extent to which your network does.
[31:19.380 --> 31:23.420]  But I think there's some interesting research to be done there.
[31:23.480 --> 31:25.400]  And I definitely don't want to knock on Freenet.
[31:25.520 --> 31:26.160]  I think it's awesome.
[31:26.200 --> 31:28.060]  And I think you should all go check it out.
[31:30.820 --> 31:32.860]  And there are some known attacks on Freenet.
[31:32.860 --> 31:36.080]  Like Pitch Black is the big one, but they're working on it.
[31:36.380 --> 31:40.420]  That's basically where they...
[31:40.420 --> 31:51.560]  In order to create this small world structure in key space, different nodes swap their IDs with each other based on information they exchange.
[31:51.560 --> 31:53.940]  But by exchanging...
[31:55.280 --> 32:02.740]  By exchanging false information, they can compel other nodes to make them more central.
[32:03.120 --> 32:04.820]  But like I said, they're working on it.
[32:05.700 --> 32:11.300]  The other technology I want to mention is an algorithm.
[32:11.700 --> 32:15.340]  The Fiat Saia algorithm, which was published in 2002.
[32:15.960 --> 32:19.960]  I don't know of any actual implementations or anyone running this.
[32:21.020 --> 32:27.240]  But it's one of the only other network-based approaches to attack tolerance that I've seen.
[32:28.520 --> 32:29.940]  So I wanted to mention it.
[32:30.560 --> 32:32.080]  It's a no-trust model.
[32:32.080 --> 32:33.520]  So you don't have to trust anyone.
[32:33.980 --> 32:35.000]  It's randomized.
[32:35.360 --> 32:41.180]  So it effectively assigns different nodes to groups.
[32:41.540 --> 32:45.600]  And then each node gets connected to every node in another group.
[32:45.600 --> 32:49.920]  So it creates this kind of highly random, highly connected network.
[32:51.920 --> 32:57.040]  But it also has some problems with replication, the size of replication.
[32:57.700 --> 33:01.920]  You need to wind up storing nearly all of the data on every node.
[33:02.220 --> 33:05.960]  Which kind of, you know, doesn't really buy you a whole lot.
[33:09.380 --> 33:12.020]  So, back to our quote.
[33:12.400 --> 33:17.460]  Back to our vision of the Internet helping us solve censorship and social problems.
[33:18.620 --> 33:19.960]  We're not there yet.
[33:21.160 --> 33:24.840]  The Internet is really resistant to random failure.
[33:25.960 --> 33:28.140]  There is some promising work.
[33:28.720 --> 33:34.620]  Both what I'm doing and what a lot of people have been working really hard on for the past decade, two decades.
[33:35.420 --> 33:36.940]  That are leading us in that direction.
[33:37.700 --> 33:41.200]  So I'd encourage you not to get complacent.
[33:41.760 --> 33:46.560]  But to also, you know, and to work on this stuff.
[33:46.800 --> 33:49.640]  And to remember that it's a good goal.
[33:49.760 --> 33:52.700]  That's going to help people in the real world.
[33:54.000 --> 33:55.400]  And it's something that we can do.
[33:56.720 --> 33:58.360]  And I'd like to...
[33:58.360 --> 34:04.140]  I'd also like to say that there's a surprisingly little amount of work on this going on in academia.
[34:04.420 --> 34:05.700]  At least it gets published.
[34:07.080 --> 34:09.500]  That may be because the work's not happening.
[34:09.820 --> 34:15.160]  Or it may be because the work is happening in corporations.
[34:15.160 --> 34:16.180]  It's proprietary.
[34:16.660 --> 34:19.120]  It may be happening but not getting published.
[34:20.040 --> 34:23.520]  I've actually talked to other people, Freenet developers.
[34:24.500 --> 34:26.620]  It can be difficult to get this work published.
[34:26.660 --> 34:31.760]  Because it's kind of different from a lot of things that are going on out there right now.
[34:32.820 --> 34:35.760]  So it can be difficult to get it through the publication process.
[34:37.020 --> 34:39.060]  Reviewer number two, I'm talking to you.
[34:39.260 --> 34:40.040]  You know who you are.
[34:44.060 --> 34:46.460]  And I just want to end with kind of a...
[34:46.460 --> 34:53.160]  You know, my vision of how we can start improving the state of censorship on the Internet.
[34:53.160 --> 35:01.440]  You know, right now we have a lot of companies that are keeping users' data on the cloud in these data silos.
[35:01.860 --> 35:04.800]  That create a huge potential for censorship.
[35:05.220 --> 35:10.980]  And are kind of accidentally inflicting censorship on all of the users right now.
[35:10.980 --> 35:15.040]  But using some of the technologies that I've described.
[35:15.040 --> 35:16.680]  Other technologies like them.
[35:17.120 --> 35:23.600]  We could replace this with a storage... a distributed storage infrastructure.
[35:24.720 --> 35:31.240]  With networks of libraries, hackerspaces, other institutions committed to free expression.
[35:32.080 --> 35:35.200]  Where users have control over their own data.
[35:36.840 --> 35:40.000]  And get to choose who they share it with.
[35:40.700 --> 35:42.680]  And no one can stop them from sharing it.
[35:42.880 --> 35:44.280]  So that's what I want to see.
[35:47.060 --> 35:52.460]  So with that, I'd like to thank the School of Information at the University of Michigan for funding this research.
[35:52.760 --> 35:57.180]  I'd like to thank all of you for listening to my crazy ideas and sitting through lots of math.
[35:57.880 --> 36:00.320]  And I'd love to talk to any of you more about this.
[36:00.580 --> 36:01.780]  You can reach me here.
[36:02.960 --> 36:05.340]  And now I think I've got some time for questions.
[36:10.880 --> 36:11.480]  Okay.
[36:11.680 --> 36:12.520]  Number one.
[36:14.360 --> 36:15.560]  Is there a microphone?
[36:15.880 --> 36:17.480]  Or should I just use this one?
[36:18.100 --> 36:18.700]  Okay.
[36:19.000 --> 36:21.060]  Freenet is for static file.
[36:21.320 --> 36:26.720]  So your discussion how it's going to be different in the context of dynamic data.
[36:27.360 --> 36:27.960]  Yeah.
[36:28.240 --> 36:30.220]  So that's one of the differences.
[36:30.560 --> 36:31.200]  Oh, right.
[36:31.400 --> 36:32.020]  Of course.
[36:32.260 --> 36:35.120]  So he says Freenet is for static files.
[36:35.120 --> 36:41.100]  How is my proposal different for dynamic files?
[36:41.380 --> 36:42.760]  And that's a really good point.
[36:43.220 --> 36:45.920]  Freenet is one of the content addressable networks.
[36:46.200 --> 36:53.060]  So it's really about storing a particular type of data in a way that you know you can retrieve it later.
[36:54.860 --> 36:58.140]  The proposal that I described here is really just about the network.
[36:58.360 --> 36:59.720]  So there's no storage layer.
[37:00.760 --> 37:03.720]  So this is just about the person-to-person communication.
[37:04.140 --> 37:05.780]  They're not exclusive.
[37:07.060 --> 37:21.340]  You can use content addressable networks to achieve person-to-person communication, but you just have to do it on the application layer, not on the network layer.
[37:24.140 --> 37:24.780]  Yeah.
[37:25.060 --> 37:44.220]  In order to have multiple paths across the network that are, therefore, reduce the likelihood of attacking the correct one, that would strike me as running into a bit of tension with the current public Internet architecture, where BGP creates a predictable path between any place and any other place.
[37:44.220 --> 37:50.680]  So while theoretical paths can exist, everyone knows what path will be used.
[37:50.860 --> 38:02.000]  It would strike me then that some kind of partial source routing or a different architecture from today's Internet would be the optimal way of being able to have multiple available paths.
[38:02.160 --> 38:02.720]  Is that about right?
[38:02.940 --> 38:04.020]  Yeah, that's a great point.
[38:04.160 --> 38:21.520]  So he said that with the way BGP, Border Gateway Protocol, works right now, the routes that are produced on the Internet tend to be predictable, deterministic, and it's kind of at odds with this idea of creating multiple routes between a source and a destination.
[38:22.240 --> 38:25.100]  So we might want to explore alternative architectures.
[38:25.260 --> 38:26.480]  And that's definitely true.
[38:27.020 --> 38:35.800]  I know that there's a proposal for MPTCP, multipath TCP, that might play a role in this type of architecture.
[38:36.360 --> 38:38.600]  Rhino architecture would accommodate better too.
[38:38.740 --> 38:39.180]  Wait, which one?
[38:39.300 --> 38:39.420]  Rhino.
[38:39.780 --> 38:40.140]  Rhino.
[38:40.280 --> 38:40.480]  Rhino.
[38:40.600 --> 38:42.860]  I haven't heard of that, but I'll check it out.
[38:43.300 --> 38:56.160]  And then I should also mention that there's a concept of overlay networks where you use standard point-to-point tunneling over the standard TCP routes.
[38:56.160 --> 39:00.080]  But then, on top of that, you build a virtual network.
[39:00.080 --> 39:03.000]  So you assign every node a virtual address.
[39:03.800 --> 39:07.520]  And your routes, much like Tor does, you know, so Tor does the multiple hops.
[39:07.660 --> 39:09.100]  It's a form of source.
[39:09.300 --> 39:09.760]  Yeah, yeah.
[39:10.920 --> 39:19.940]  So your route through the virtual network is completely disconnected from your route through the physical network in those cases.
[39:23.360 --> 39:23.980]  Let's see.
[39:26.060 --> 39:26.420]  David.
[39:27.980 --> 39:29.640]  So I thought this stuff was really interesting.
[39:29.760 --> 39:41.080]  I'm just curious, like, in terms of, like, for people who say, well, the Internet works, like, 99% of the time, and then want to know, like, what is going to be the cost of kind of getting this redundancy and more resilience in terms of, like, additional,
[39:41.140 --> 39:49.460]  like, lines, bandwidth lines we can delay, or just, like, performance in terms of, like, bandwidth or times to change for packets to reach their destination?
[39:50.260 --> 39:50.980]  Okay, yeah.
[39:51.180 --> 39:55.680]  So David's question is about the resources that this takes.
[39:55.940 --> 40:01.580]  And is it worth using those resources for the 1% of the time when you actually need these?
[40:02.020 --> 40:10.260]  So I would say that's kind of a challenge of the work is to find a system that does this without using too many resources.
[40:10.620 --> 40:16.960]  And probably the main trade-off there is we want very sparse networks.
[40:16.960 --> 40:25.540]  We don't want each node to have a million connections, because that eats up a lot of resources, memory for routing tables, things like that.
[40:26.660 --> 40:31.500]  But we want to be able to leverage the existing resources in the best possible way.
[40:32.220 --> 40:40.260]  There's also the kind of, you know, getting people to change and adopt new standards, you know, like we see with IP4 and IP6.
[40:41.140 --> 40:45.100]  I think that, you know, that's a difficulty you're going to have for any problem.
[40:45.360 --> 40:51.800]  So that's more of a political will, activism type question than a technical one.
[40:55.420 --> 40:56.920]  Okay, in the back.
[40:57.400 --> 41:01.180]  I had a question about the vertex transitivity of butterfly networks.
[41:01.500 --> 41:01.600]  Yep.
[41:01.640 --> 41:06.360]  When you gave the definition, it sounds like one of the requirements was that each node had the same number of connections.
[41:06.900 --> 41:11.180]  But the graph for the butterfly network didn't seem to have that property.
[41:12.340 --> 41:14.040]  Okay, smart guy, call me out here.
[41:14.940 --> 41:16.820]  So he asked about the butterfly network.
[41:17.240 --> 41:22.320]  And he said that in the graph that I showed, not every node had the same number of connections.
[41:23.440 --> 41:28.220]  So that's actually true about the plain old butterfly network.
[41:29.140 --> 41:36.720]  But what you do is, if you take all the nodes in the last column, you'll see I only have three bits here.
[41:36.900 --> 41:38.020]  But I have four columns.
[41:38.580 --> 41:46.220]  If you take every node in the last column and equate it with a node in the first column, you get a wrap around butterfly network.
[41:46.920 --> 41:48.680]  And that gives you the vertex transitivity.
[41:48.980 --> 41:51.500]  But yeah, I think we have a graph theory nerd back here.
[41:53.460 --> 41:58.740]  So for the butterfly network and the hypercube network, you mentioned...
[41:58.740 --> 42:01.080]  Oh yeah, so they both have all these nice properties.
[42:01.540 --> 42:05.460]  But you're almost never going to have exactly two to the n nodes in your network.
[42:05.900 --> 42:12.540]  If you have like two to the n plus two to the n minus one, are you still going to have any of those properties?
[42:13.220 --> 42:14.740]  Okay, yeah, so this is a good question.
[42:14.920 --> 42:24.200]  He asked, in a lot of these, the, you know, the m cube, the butterfly, you have a very specific number of nodes that you can achieve.
[42:24.460 --> 42:27.300]  You know, so in a cube, it's powers of two.
[42:28.000 --> 42:32.580]  And your social network, your communication network is usually not going to have one of those.
[42:33.420 --> 42:35.440]  There are a couple different approaches to that.
[42:35.440 --> 42:38.220]  So one, you can find approximations.
[42:39.480 --> 42:42.560]  One of the overlay networks does this with the butterfly network.
[42:42.760 --> 42:44.100]  I forget which one it is.
[42:44.840 --> 42:46.860]  I think it's Viceroy, it's called.
[42:47.640 --> 42:51.560]  So they do kind of a randomized approximation of the butterfly network.
[42:52.400 --> 43:16.060]  Another option is you can build a multiple layer network where you have a primary layer that has two to the n nodes, but then you attach clients to one of those nodes or some number of those nodes in order to kind of get the flexibility of multiple of many different node sizes,
[43:16.560 --> 43:20.080]  but still maintain the benefits of having a structured network.
[43:20.080 --> 43:21.880]  So kind of a more federated model.
[43:24.040 --> 43:33.460]  It seems to me that you've taken certain structures, networks with different structured properties, to find out what is optional for the problem.
[43:33.740 --> 43:37.360]  But in the real world, these are self-organizing networks.
[43:37.880 --> 43:46.520]  New nodes appear, and that node then has a problem of who should I connect to to provide me a service.
[43:47.620 --> 43:57.020]  And those criteria are probably forcing the network into a structure that you very much don't want to have.
[43:57.340 --> 44:07.180]  So the question may be, how do you set up a set of rules for self-organizing networks that the resulting network can be guaranteed?
[44:08.040 --> 44:08.860]  Yeah, exactly.
[44:09.280 --> 44:15.080]  So for the first part of your question, I was going to say we found reviewer number two, but you've got my response already.
[44:15.300 --> 44:22.500]  So he said, in reality, a lot of the networks that we care about are self-organizing.
[44:22.500 --> 44:29.740]  They follow rules that aren't necessarily compatible with the very structured, very regular networks that I've presented.
[44:30.440 --> 44:31.780]  And that's totally true.
[44:32.880 --> 44:44.920]  So one approach to that, which he mentioned, is you can start to say, well, what are the rules we would need to follow so that we start to build these types of networks?
[44:44.980 --> 44:48.880]  And that's definitely one thing that I'm actively looking into in my research.
[44:49.440 --> 44:57.640]  And then the other answer to that is, right now, we build our networks in a self-organized way.
[44:58.900 --> 45:03.280]  But it may be the case that we want to build some networks in a more deliberate way.
[45:03.480 --> 45:12.280]  In the kind of example I talked about with organizations of libraries, hackerspaces, working together, we have a power grid.
[45:12.540 --> 45:14.220]  Why can't we have a trust grid?
[45:14.220 --> 45:20.900]  This is something that it might be worth having if it gives us something that we didn't have before.
[45:23.730 --> 45:24.290]  Yeah.
[45:24.510 --> 45:31.070]  I have a question about the trade-off between speed of interactions and building complex resilient models.
[45:31.350 --> 45:36.830]  So you talk about a lot of, to my mind, it's very theoretical models, maybe.
[45:36.830 --> 45:46.250]  So when you try to apply it on top of Internet, you might maybe have something that is very resilient but also very slow to communicate between people.
[45:46.450 --> 45:47.830]  Is it the case or...?
[45:47.830 --> 45:48.330]  Yeah.
[45:48.890 --> 45:53.770]  I mean, so I haven't tried building any of these, but it's definitely the case with the ones that I've seen out there.
[45:53.770 --> 46:00.890]  You know, Freenet, Tor, they're definitely working on finding ways to trade off...
[46:00.890 --> 46:01.470]  Oh, sorry.
[46:01.550 --> 46:08.830]  The question was about the trade-off between performance and reliability and fault tolerance and censorship resistance.
[46:09.370 --> 46:10.930]  And yeah, there's a trade-off there.
[46:12.070 --> 46:16.730]  So there's some theoretical research on how do you achieve that trade-off.
[46:17.290 --> 46:25.910]  And then there's also more practical engineering-based research on, you know, how do you optimize and tweak your solution once you've found it.
[46:26.730 --> 46:28.010]  Do you have time for...?
[46:29.690 --> 46:30.250]  Okay.
[46:30.450 --> 46:30.630]  Yeah.
[46:30.790 --> 46:31.730]  A couple more questions.
[46:32.850 --> 46:33.550]  Thank you.
[46:34.230 --> 46:43.230]  You've reduced in your model, you've reduced these longer paths to single points to simplify the analysis, saying that it's going to compromise one point in the path.
[46:43.450 --> 46:47.010]  But it seems to me that a longer path has more possible points to compromise.
[46:47.770 --> 46:58.190]  Doesn't that mean that there is a simplification that you want to prefer shorter paths because the likelihood of the amount is compromised in the individual node would be relevant there?
[46:58.190 --> 47:07.830]  Okay, so the question was, in this partial trust model, I've simplified the untrusted region to a number of paths with a single node.
[47:08.870 --> 47:21.410]  And the argument was, some paths will have multiple nodes, which will have more possible chances for male to compromise those nodes.
[47:21.550 --> 47:23.010]  So you might want to prefer short nodes.
[47:24.030 --> 47:30.710]  Well, so that's true if male doesn't know the structure of the network, if male is just compromising nodes randomly.
[47:31.570 --> 47:34.550]  I'm actually choosing an even more adversarial model.
[47:34.830 --> 47:38.950]  So I'm being my own enemy here and saying, male knows the structure of the network.
[47:39.150 --> 47:44.490]  Male knows which nodes to compromise so that she only has to do one per path.
[47:45.430 --> 47:50.250]  And all of the results that I've presented still hold in that kind of really pessimistic case.
[47:50.250 --> 47:55.650]  Except in the case where you're directly connected to someone that you want to exchange a message with.
[47:56.310 --> 47:58.190]  Which would always be the optimal case.
[47:58.350 --> 47:58.810]  Right, right.
[47:58.950 --> 48:02.570]  Unless you're directly connected to someone or you share trust neighborhoods.
[48:04.170 --> 48:10.330]  So you made the simplifying assumption that you have this sort of just basically distinct paths.
[48:10.450 --> 48:13.950]  But really you have this kind of big mesh full of stuff.
[48:13.950 --> 48:22.790]  And so somehow you are like A, if A is routing a message to B, A has to kind of pick out a bunch of nodes in the middle to create these independent paths.
[48:23.490 --> 48:26.810]  How do you sort of avoid that being compromised?
[48:26.810 --> 48:30.670]  How do you even get a picture of the network in the middle to safely choose your paths?
[48:31.030 --> 48:31.730]  Oh, perfect question.
[48:31.770 --> 48:32.910]  I'm really glad you asked that.
[48:33.150 --> 48:40.610]  So the question was, in this model we just have some paths and Alice is just choosing some of those paths.
[48:41.410 --> 48:49.630]  And the question was, how does Alice know in the real network, in the more complicated one, how does Alice know which nodes to send those paths?
[48:49.830 --> 48:50.990]  How to route the messages?
[48:51.350 --> 48:55.270]  And that's a real kind of challenge in this type of work.
[48:55.330 --> 49:02.190]  And some of the work that I'm doing is on finding routing algorithms that do exactly that.
[49:02.350 --> 49:03.490]  So it's not straightforward.
[49:03.710 --> 49:04.350]  It's non-trivial.
[49:05.170 --> 49:06.250]  I'm working on it.
[49:06.730 --> 49:07.990]  I do have...
[49:07.990 --> 49:10.690]  I'm hoping to publish within the next year.
[49:11.530 --> 49:21.930]  There's kind of a single path routing algorithm that the butterfly applies where, you know, if you want to get from 0 to 101, you need to flip the first and the last bit.
[49:22.890 --> 49:23.290]  So...
[49:23.290 --> 49:26.450]  Or we'll say to 001, you just need to flip the last bit.
[49:26.570 --> 49:27.390]  So you go...
[49:28.190 --> 49:28.590]  Or...
[49:28.590 --> 49:29.330]  No, the first bit.
[49:29.490 --> 49:29.590]  Right.
[49:30.230 --> 49:30.630]  Indexing.
[49:30.770 --> 49:33.030]  Yeah, so you go down here and then you just go like that.
[49:34.150 --> 49:36.270]  So there's a natural routing algorithm.
[49:36.490 --> 49:47.930]  I've done some work that extends that to multipath routing algorithms that actually generates 2 to the H non-overlapping paths for the butterfly network.
[49:47.930 --> 49:48.710]  So you can do that.
[49:51.070 --> 49:51.690]  And...
[49:51.690 --> 49:52.310]  Okay.
[49:52.470 --> 49:52.830]  I'm done.
[49:53.110 --> 49:53.930]  Thank you all.
[49:53.930 --> 49:53.990]  Thank you all.