0:00:00.000,0:00:19.237
35C3 preroll music
0:00:19.237,0:00:24.970
Herald Angel: All right. It's my very big[br]pleasure to introduce Roya Ensafi to you.
0:00:24.970,0:00:31.390
She's gonna talk about "Censored Planet: a[br]Global Censorship Observatory". I'm
0:00:31.390,0:00:36.230
personally very interested in learning[br]more about this project. Sounds like it's
0:00:36.230,0:00:41.490
gonna be very important. So please welcome[br]Roya with a huge warm round of applause.
0:00:41.490,0:00:42.880
Thank you.
0:00:42.880,0:00:48.660
Applause
0:00:48.660,0:00:56.170
Roya: It's wonderful to finally make it to[br]CCC. I had joined talk with multiple of my
0:00:56.170,0:01:00.219
friends over the past years and the visa[br]stuff never worked out. This year I
0:01:00.219,0:01:06.430
applied for a conference in August and the[br]visa worked for coming to CCC. My name is
0:01:06.430,0:01:11.170
Roya Ensafi and I'm professor at the[br]University of Michigan. My research
0:01:11.170,0:01:18.069
focuses on security and privacy with the[br]goal of protecting users from adversarial
0:01:18.069,0:01:27.799
network. So basically I investigate[br]network interference ...and somebody is
0:01:27.799,0:01:55.770
interfering right now. Damn it. What the[br]heck. Cool, I'm good. Oh, no I'm not.
0:01:55.770,0:02:07.639
laughter OK. In my lab we develop[br]techniques and systems to be able to
0:02:07.639,0:02:13.800
detect network interference often at a[br]scale and apply these frameworks and tools
0:02:13.800,0:02:20.060
to be able to understand the behaviors of[br]these actors that do the interference and
0:02:20.060,0:02:25.040
use this understanding to be able to come[br]up with a defense. Today I'm going to talk
0:02:25.040,0:02:30.030
about a project that is very dear to my[br]heart. The one that I spent six years
0:02:30.030,0:02:34.560
working on it. And in this talk I'm going[br]to talk about censorship, internet
0:02:34.560,0:02:41.391
censorship. And by that I mean any action[br]that prevents users' access to the
0:02:41.391,0:02:48.720
requested content. We have heard an[br]alarming level of censorship happening all
0:02:48.720,0:02:53.980
around the world. And while it was[br]previously multiple countries that were
0:02:53.980,0:03:01.260
capable of using deep packet inspections[br]to tamper with user traffic thanks to
0:03:01.260,0:03:08.540
commercialization of these DPIs now many[br]countries are actually messing with users'
0:03:08.540,0:03:16.951
data. For the first time that the users[br]type CNN.com in their browsers, their
0:03:16.951,0:03:22.320
traffic is subject to some level of[br]interference by different actors. First
0:03:22.320,0:03:27.150
for example the DNS query where the[br]mapping between the domain and the IP
0:03:27.150,0:03:34.100
where the content is, can be manipulated.[br]For example the DNS assets can be a dead
0:03:34.100,0:03:40.900
IP where the content is not there. If the[br]DNS succeed then the users and the servers
0:03:40.900,0:03:47.500
are going to establish a connection, TCP[br]handshake and that can be easily blocked.
0:03:47.500,0:03:53.840
If that succeed then users and servers[br]start actually sending back and forth the
0:03:53.840,0:04:00.209
actual data and there are enough to clear[br]text to be the traffic encrypted or not
0:04:00.209,0:04:06.130
that the DPI can detect a sensitive[br]keyboard and send a reset package to both
0:04:06.130,0:04:12.990
basically shut down the connections.[br]Before I forget let me tell you and
0:04:12.990,0:04:18.150
emphasize that it's not just the[br]governments and the policies that impose
0:04:18.150,0:04:25.400
on the ISPs that lead to censorship.[br]Actually server side which provides the
0:04:25.400,0:04:31.319
data are also blocking users. Especially[br]if they are located in a region that they
0:04:31.319,0:04:39.580
don't provide any revenue. We recently[br]investigated this issue of dual blocking
0:04:39.580,0:04:49.180
in deep and provide more details about[br]what role CDNs actually provide. Imagine
0:04:49.180,0:04:57.490
now we have how many users, how many ISPs,[br]how many transit networks and how many
0:04:57.490,0:05:02.830
websites. Each of which are going to have[br]their own policies of how to block users'
0:05:02.830,0:05:09.859
access. More, censorship changes from time[br]to time, region to region and country to
0:05:09.859,0:05:14.759
country. And for that reason many[br]researchers including me have been
0:05:14.759,0:05:20.660
interested in collecting data about[br]censorship in a global way and
0:05:20.660,0:05:29.539
continuously. Well, I grew up under severe[br]censorship. Be it the university,
0:05:29.539,0:05:35.289
government, more frustrating the server[br]side. And I genuinely believe that
0:05:35.289,0:05:44.739
censorship take away opportunities and[br]degrade human dignity. It is not just
0:05:44.739,0:05:54.090
China, Bahrain, Turkey that does internet[br]censorship. Actually with the DPIs become
0:05:54.090,0:06:02.499
cheaper and cheaper many governments are[br]following their leads. As a result
0:06:02.499,0:06:06.680
Internet is becoming more and more[br]balkanized and the users around the world
0:06:06.680,0:06:09.870
are going to soon have a very very[br]different pictures of what this Internet
0:06:09.870,0:06:16.500
is. And we need to be able to collect the[br]data and to be able to know what is being
0:06:16.500,0:06:25.121
censored, how it's being censored, where[br]it's being censored and for how long. This
0:06:25.121,0:06:32.509
data then can be used to bring[br]transparency and accountability to
0:06:32.509,0:06:38.779
governments or private companies that[br]practice internet censorship. It can help
0:06:38.779,0:06:44.460
us to know where the circumvention to,[br]where the defense needs to be deployed. It
0:06:44.460,0:06:49.309
can help us to let the users around the[br]world to know what their governments are
0:06:49.309,0:06:59.370
up to and more important provide valid and[br]good data for the policymakers to come up
0:06:59.370,0:07:07.860
with the good policies. Existing research[br]already shows that if we can provide this
0:07:07.860,0:07:17.860
data to users they act by their own will[br]to ensure Internet freedom. For many years
0:07:17.860,0:07:22.619
my goal has been to come up with a weather[br]map, a censorship weather map where you
0:07:22.619,0:07:27.199
can actually see changes in censorship[br]over time, how some countries are
0:07:27.199,0:07:34.100
different from others and do that for a[br]continuous duration of time, and for all
0:07:34.100,0:07:41.710
over the world. Creating such a map was[br]impossible with the techniques, Internet
0:07:41.710,0:07:46.919
measurement methods that we had at that[br]time. At the time and even the common
0:07:46.919,0:07:53.779
techniques we now use. The measurement[br]methods to be able to use for measuring
0:07:53.779,0:07:59.080
internet censorship is often by deploying[br]a software or giving your customized
0:07:59.080,0:08:05.689
Raspberry Pi to either a client or a[br]server and based on that measure what's
0:08:05.689,0:08:12.550
happening between client and servers.[br]Well, this approach has a lot of
0:08:12.550,0:08:18.050
limitations. For example there are not[br]that many volunteers around the whole
0:08:18.050,0:08:25.409
world that are eager to download a[br]software and run it. Second, the data
0:08:25.409,0:08:33.190
collected from this approach are often not[br]continuous because the user's connection
0:08:33.190,0:08:37.960
can die for a variety of reasons or users[br]may loose interest to keep running the
0:08:37.960,0:08:45.450
software. And therefore we end up with[br]sparse data where we cannot have a good
0:08:45.450,0:08:53.450
baseline for internet censorship studies.[br]More measuring domains that are sensitive
0:08:53.450,0:08:59.800
often create risks for the local[br]collaborators and might end up with their
0:08:59.800,0:09:09.810
government's retaliate. These risks are[br]not hypothetical. When the Arab Spring was
0:09:09.810,0:09:17.240
happening I was approached by many[br]colleagues to recruit local friends and
0:09:17.240,0:09:24.340
colleagues in Middle East to be able to[br]collect measurement data at the time that
0:09:24.340,0:09:30.010
was very interesting to capture the[br]behavior of the network and most dangerous
0:09:30.010,0:09:36.450
for the locals, and volunteers to collect[br]that. My painting actually expressed what
0:09:36.450,0:09:44.090
I felt at the time. I can't just imagine[br]asking people on the ground to help at
0:09:44.090,0:09:54.810
these times of unrest. In my opinion,[br]conspiring to collect the data against the
0:09:54.810,0:10:02.450
government's interest can be seen as an[br]act of treason. And these governments are
0:10:02.450,0:10:11.770
unpredictable often. So it has exposed[br]these volunteers to a severe risk. While
0:10:11.770,0:10:19.030
no one has yet been arrested because of[br]measuring internet censorship as far as we
0:10:19.030,0:10:25.740
know, and I don't know how we can know[br]that on a global scale, I think the clouds
0:10:25.740,0:10:34.210
are on the horizon. I'm still at awe how[br]Turkish government used their surveillance
0:10:34.210,0:10:42.410
data at a time of a co-op and tracked down[br]and detained hundreds of users because
0:10:42.410,0:10:49.400
there was a traffic between them and by[br]luck a messenger app that was used by co-
0:10:49.400,0:10:57.410
op administrators. These things happens.[br]Before I continue, if you know OONI you
0:10:57.410,0:11:08.091
might ask how OONI prevents risk. Well,[br]with a great level of efforts. And if you
0:11:08.091,0:11:12.130
don't know OONI, OONI is a global[br]community of volunteers that collect data
0:11:12.130,0:11:20.840
about censorship around the world. Well,[br]first and foremost they provide their
0:11:20.840,0:11:27.990
volunteers with the very honest consent,[br]telling them that "hey, if you run this
0:11:27.990,0:11:34.560
software, anybody who is monitoring your[br]traffic know what you're up to." They also
0:11:34.560,0:11:39.390
go out of their way to give freedom to[br]these volunteers to choose what website
0:11:39.390,0:11:46.010
they want to run, what data they want to[br]push. They establish a great relationship
0:11:46.010,0:11:53.940
with the local activist organization in[br]the countries. Well, now that I prove to
0:11:53.940,0:11:59.250
you guys that I am a supporter of OONI and[br]I am actually friends with most of them; I
0:11:59.250,0:12:05.300
want to emphasize that I still believe[br]that consistent and continuous and global
0:12:05.300,0:12:12.200
data about censorship requires a new[br]approach that doesn't need volunteers'
0:12:12.200,0:12:21.880
help. I've become obsessed with solving[br]this problems. What if we could measure
0:12:21.880,0:12:29.160
without a client, in anywhere around the[br]world, can talk to a server without being
0:12:29.160,0:12:36.290
close to a client. Somewhere from here,[br]from University of Michigan. And see
0:12:36.290,0:12:42.300
whether the two hosts can talk to each[br]other, globally and remotely, off the
0:12:42.300,0:12:50.220
path. When I talk to the people about[br]this, honestly, everybody was like "you
0:12:50.220,0:12:54.190
don't know what you're talking about, it's[br]really really challenging". Well, they
0:12:54.190,0:13:01.370
were right. The challenge is there, and[br]I'm going to walk you through it. We have
0:13:01.370,0:13:06.760
at least 140 million IP addresses that[br]respond to same packet. This means they
0:13:06.760,0:13:15.530
speak to the world, and they follow[br]blindly TCP/IP protocol. So the question
0:13:15.530,0:13:24.400
becomes: how can I leverage the subtle[br]properties of TCP/IP to be able to detect
0:13:24.400,0:13:36.080
that two hosts can talk to each other?[br]Well, Spooky Scan is a technique that Jed
0:13:36.080,0:13:43.090
Crandall from University of New Mexico and[br]I developed that uses TCP/IP side channels
0:13:43.090,0:13:49.770
to be able to detect whether the two[br]remote hosts can establish a TCP handshake
0:13:49.770,0:13:56.890
or not, and if not, in which direction the[br]packets are being dropped. Off the path
0:13:56.890,0:14:03.780
and remotely. And I'm gonna start telling[br]you how this works. First I have to cover
0:14:03.780,0:14:10.810
some background. So any connection that is[br]based on TCP, one of the basic
0:14:10.810,0:14:15.950
communication protocols we have, is it[br]needs to establish a TCP handshake. So
0:14:15.950,0:14:22.730
basically you should, you send a SYN and[br]in the packet you send, in the IP header,
0:14:22.730,0:14:30.750
you have a field called "identification[br]IP_ID", and this field is used for
0:14:30.750,0:14:36.610
fragmentation reason, and I'm going to use[br]this field a lot in the rest of the talk.
0:14:36.610,0:14:42.300
After the user received a SYN, it is going[br]to send a SYN-ACK back, have another IP_ID
0:14:42.300,0:14:47.520
in it. And then, if I want to establish a[br]connection I send ACK. Otherwise I send a
0:14:47.520,0:14:56.070
RESET (RST). Part of the protocol says[br]that if you send a SYN-ACK packet to a
0:14:56.070,0:15:01.310
machine with a port open or closed, it's[br]going to send you a RST, telling you "what
0:15:01.310,0:15:05.220
the heck you are sending me SYN-ACK, I[br]didn't send you a SYN" and another part
0:15:05.220,0:15:09.350
said: if you send a SYN packet to a[br]machine with the port open, eager to
0:15:09.350,0:15:13.880
establish connection, it will send you a[br]SYN-ACK. If you don't do anything, because
0:15:13.880,0:15:20.040
TCP/IP is reliable, it's going to send you[br]multple SYN-ACK. It depends on operating
0:15:20.040,0:15:30.241
system, 3, 5, you name it. Spooky Scan[br]requires some basic characteristics. For
0:15:30.241,0:15:36.740
example, the client, the vantage points[br]that we are interested, should maintain a
0:15:36.740,0:15:44.060
global variable for the IP_ID. It means[br]that, when they receive the packets and
0:15:44.060,0:15:48.650
they want to send a packet out, no matter[br]who they're sending the packet to, this
0:15:48.650,0:15:53.590
IP_ID is going to be a shared resource, as[br]in going to be increment by one. So by
0:15:53.590,0:15:57.900
just watching the IP_ID changes you can[br]see how much a machine is noisy, how much
0:15:57.900,0:16:03.820
a machine is sending traffic out. A server[br]should have a port open, let's say 80 or
0:16:03.820,0:16:08.910
443, and wants to establish a connection,[br]and the measurement machine, me, should be
0:16:08.910,0:16:15.360
able to spoof packets. It means sending[br]packet with the source IP different from
0:16:15.360,0:16:20.520
my own machine. To be able to do that, you[br]need to talk to upstream network and ask
0:16:20.520,0:16:28.260
them not to drop the packets. All of these[br]requirements I could easily satisfy with a
0:16:28.260,0:16:36.560
little bit of effort. A Spooky Scan starts[br]with measurement machine send a SYN-ACK
0:16:36.560,0:16:41.310
packet to one of this client with a global[br]IP_ID, at a time let's say the value is
0:16:41.310,0:16:49.010
7000. The client is going to send back a[br]RST, following the protocol, revealing to
0:16:49.010,0:16:53.881
me what the value of IP_ID. In the next[br]step I'm going to send a spoofed SYN
0:16:53.881,0:17:01.779
packet to a server using a client IP. As a[br]result, the SYN-ACK is going to be sent to
0:17:01.779,0:17:06.289
the client. Again, client is going to send[br]a RST back, the IP_ID is going to be
0:17:06.289,0:17:11.240
incremented by 1. Next time I query IP_ID[br]I'm going to see a jump too. In a
0:17:11.240,0:17:17.189
noiseless model, I know that this machine[br]talked to the server. If I query it again,
0:17:17.189,0:17:25.070
I won't see any jump. So, Delta 2, Delta[br]1. Now imagine there is a firewall that
0:17:25.070,0:17:32.520
blocks the SYN-ACKs going from the server[br]to the client. Well, it doesn't matter how
0:17:32.520,0:17:36.860
much of the traffic I send, it's not going[br]to get there. It's not going to get there.
0:17:36.860,0:17:44.390
So the delta I see is 1, 1. In the third[br]case when the packets are going to be
0:17:44.390,0:17:49.790
dropped from the client to the server:[br]Well, my SYN-ACK gets there. The SYN-ACK
0:17:49.790,0:17:55.030
gets to the client, the client is going to[br]set the RST back, but it's not going to
0:17:55.030,0:17:59.470
get to the server. And so server thinks[br]that a packet got dropped, so it's going
0:17:59.470,0:18:07.040
to send multiple SYN-ACK. And as a result[br]the RST is going to be plus plus more. And
0:18:07.040,0:18:13.690
so what jump I would see is, let's say, 2,[br]2. Let me put them all together. So you
0:18:13.690,0:18:19.670
have 3 cases. Blocking in this direction.[br]No blocking and blocking in the other. And
0:18:19.670,0:18:25.890
you see different jumps or different[br]deltas. So it's detectable. Yes, yes, in a
0:18:25.890,0:18:31.770
noiseless model. I know the clients talk[br]to so many others and the IP_ID is going
0:18:31.770,0:18:37.590
to be changed because of a variety of[br]reason. I call all of those noise. And
0:18:37.590,0:18:42.870
this is how we are going to deal with it.[br]Well, intuitively thinking we can amplify
0:18:42.870,0:18:47.940
the signal. We can actually instead of[br]sending one spoofed SYN packet we can send
0:18:47.940,0:18:55.310
n. And for a variety of reasons packets[br]can get dropped. So we need to repeat this
0:18:55.310,0:19:04.360
measurement. So here is some data from a[br]Spooky Scan where I used the following
0:19:04.360,0:19:13.300
probing method. For 30 seconds I spoofed[br]the, I've sent a query for IP_ID. And then
0:19:13.300,0:19:20.559
for another 30 seconds I send these 5[br]spoofed SYN packets. This is machines or
0:19:20.559,0:19:26.680
clients in Azerbaijan, China and United[br]States. And we wanted to check whether it
0:19:26.680,0:19:32.980
has reached the TOR-relay that we had in[br]Sweden. You can see there are different
0:19:32.980,0:19:40.280
jump or different levels-shift that you[br]observe in a second phase. And just
0:19:40.280,0:19:45.290
visually looking at it or using auto-[br]regressive moving average or ARMA you
0:19:45.290,0:19:51.120
can actually detect that. But there is an[br]insight here, which is that not all the
0:19:51.120,0:19:56.520
clients have the same level of noise. And[br]for which, for some of them, especially
0:19:56.520,0:20:01.630
these guys, you could easily detect after[br]five level of sending IP_ID-query and then
0:20:01.630,0:20:10.770
five seconds of spoofing. So in the[br]follow-up work we tried to use this
0:20:10.770,0:20:16.480
insight, to be able to come up with a[br]scalable and efficient technique to be
0:20:16.480,0:20:24.900
able to use it in a global way. And that[br]technique is called "Augur". Well Augur
0:20:24.900,0:20:32.920
adopts this probing method. First, for four[br]seconds it queries IP_ID, then in one
0:20:32.920,0:20:42.160
second sends 10 spoofed SYN-packets. Then[br]look at the IP_ID-acceleration or second
0:20:42.160,0:20:49.600
derivative, and see whether we see a jump,[br]a sudden jump at the time of perturbation,
0:20:49.600,0:20:55.520
when we did the spoofing. How confident we[br]are that that jump is the result of our
0:20:55.520,0:21:02.290
own spoofed packet? Well, I'm not[br]confident, run it again. I think so, run
0:21:02.290,0:21:09.280
it again, until you have a sufficient[br]confidence. It turns out there is a
0:21:09.280,0:21:15.230
statistical analysis called "sequential[br]hypothesis testing" that can be used to be
0:21:15.230,0:21:23.300
able to gradually improve our confidence[br]about the case we're detecting. So I'm
0:21:23.300,0:21:28.340
going to give you a very, very rough[br]overview of how this works. But for
0:21:28.340,0:21:36.810
sequential hypothesis testing we need to[br]define a random variable. And we use
0:21:36.810,0:21:42.910
IP_ID-acceleration at the time of[br]perturbation, being 1 or 0, based on you
0:21:42.910,0:21:53.570
see jump or not. We also need to calculate[br]some empirical priors, known
0:21:53.570,0:21:59.450
probabilities. If you look at everything,[br]what would be the probability that you see
0:21:59.450,0:22:08.179
jump when there is actually no blocking?[br]And so on. After we put all this together
0:22:08.179,0:22:16.150
then we can formalize an algorithm[br]starting by run a trial. Update the
0:22:16.150,0:22:20.940
sequence of values for the random[br]variables. Then check whether this
0:22:20.940,0:22:27.320
sequence of values belongs to the[br]distribution of where the blocking happen
0:22:27.320,0:22:32.590
or not. What's the likelihood of that? If[br]you're confident, if we reached the level
0:22:32.590,0:22:39.130
that we are satisfied, then we call it a[br]case. So putting all this together this is
0:22:39.130,0:22:47.720
how Augur works. We scan the whole IPv4,[br]find global IP_ID-machines. And then we
0:22:47.720,0:22:55.870
have some constraint that is it a stable[br]machine? Is it a noisier or have a noise
0:22:55.870,0:23:02.170
that you want to deal with? We also need[br]to figure out what website are we
0:23:02.170,0:23:09.290
interested to test reachability towards?[br]What countries we are? So after we decide
0:23:09.290,0:23:18.500
all the input then we run a scheduler[br]making sure that no client and server are
0:23:18.500,0:23:26.160
under the measurement in the same time[br]because they mess each other's detection.
0:23:26.160,0:23:32.500
And then we actually use our analysis to[br]be able to call the case and summarize the
0:23:32.500,0:23:39.191
results. I started by saying that the[br]common methods have this limitation, for
0:23:39.191,0:23:45.370
example coverage continuity and ethics.[br]Well, when it comes to coverage there are
0:23:45.370,0:23:52.620
more than 22-million global IP_ID-[br]machines. These are WindowsXP or
0:23:52.620,0:24:02.570
predecessors. And FreeBSDs for[br]example. Compared to the previous board,
0:24:02.570,0:24:07.910
one successful project is the RIPE-atlas,[br]and they have around 10000 probes globally
0:24:07.910,0:24:18.970
deployed. When it comes to continuity we[br]don't depend on the end user. So it's much
0:24:18.970,0:24:28.720
more reliable to use this. Well, by not[br]asking volunteers to help we were already
0:24:28.720,0:24:34.570
reducing the risk. Because there is no[br]users conspiring against their governments
0:24:34.570,0:24:43.000
to collect this data. But our approach is[br]not also zero risk. If you look you have a
0:24:43.000,0:24:49.860
different kind of risk here. The client[br]and server exchanging SYN-ACK and RST
0:24:49.860,0:24:55.810
without each of them giving a consent. And[br]we don't want to ask for consent. Because
0:24:55.810,0:25:01.020
if you do, the dilemma exists. We have to[br]go back and it's just the same that's
0:25:01.020,0:25:06.850
asking volunteers. So, to deal with that[br]and cope with that, to reduce the risk
0:25:06.850,0:25:15.380
more, we don't use end-IPs. We actually[br]use 2 hops back, routers which high
0:25:15.380,0:25:21.650
probability they are infrastructure[br]machines and use those as a vantage point.
0:25:21.650,0:25:31.486
Even in this harsh constraint we still[br]have 53000 global IP_ID-routers. To test
0:25:31.486,0:25:38.780
the framework to see that whether Augur[br]works we chose 2000 of these global IP_ID-
0:25:38.780,0:25:45.350
machines, uniformly selected from all the[br]countries we had vantage point. We
0:25:45.350,0:25:52.549
selected websites from Citizen Lab[br]Testlist. This is the research
0:25:52.549,0:25:57.710
organization in Toronto University where[br]they crowdsourced websites that are
0:25:57.710,0:26:03.070
potentially being blocked or potential[br]sensitive. And then we used thousands of
0:26:03.070,0:26:09.640
the websites from Alexa top-10k. And then[br]we get the Augur running for 17 days and
0:26:09.640,0:26:17.050
collect this data. One of the challenges[br]that we have to validate Augur was like:
0:26:17.050,0:26:22.940
So, what is the truth? What is the ground-[br]truth? What would we see that makes sense?
0:26:22.940,0:26:26.270
So, and this is the biggest and[br]fundamental challenge for internet-
0:26:26.270,0:26:33.570
censorship anyway. But so the first[br]approach is leaning on intuition, which is
0:26:33.570,0:26:40.049
like no client should show blocking[br]towards all the websites. No server should
0:26:40.049,0:26:45.740
show blocking for bulk of our clients. And[br]if anything happens like that we just
0:26:45.740,0:26:51.960
trash it. And we should see more bias[br]towards the sensitive domain versus the
0:26:51.960,0:27:01.559
ones that are popular. And so on. And also[br]we hope to replicate the anecdotes, the
0:27:01.559,0:27:08.870
reports out there. And we did all of[br]those. And that's how we validate Augur.
0:27:08.870,0:27:17.690
So at the end Augur is a system that is as[br]scalable and efficient, ethical and can be
0:27:17.690,0:27:24.630
used to detect TCP/IP-blocking[br]continuously. Yes I know that is just
0:27:24.630,0:27:32.310
TCP/IP. What about the other layers? Can[br]we measure them remotely as well? Well,
0:27:32.310,0:27:40.090
let me focus on the DNS. You might ask: Is[br]there a way that we can remotely detect
0:27:40.090,0:27:46.890
DNS poisoning or manipulation? Well let's[br]think it out loud. From now on I'm gonna
0:27:46.890,0:27:54.370
give just the highlights of the papers we[br]work for the lack of the time. Well, if we
0:27:54.370,0:28:06.070
scan the whole IPv4 we have a lot of open[br]DNS resolvers, which means that they are
0:28:06.070,0:28:14.929
open to anybody sending a query to them to[br]resolve. And these open DNS-resolvers can
0:28:14.929,0:28:22.590
be used as a vantage point. We can use[br]open DNS-resolvers in different ISPs
0:28:22.590,0:28:29.830
around the world to see whether that DNS[br]queries are poisoned or not. Well, wait.
0:28:29.830,0:28:35.419
We need to make sure that they don't[br]belong to the end user. So we come up with
0:28:35.419,0:28:42.760
a lot of checks to make sure that these[br]open DNS-resolvers are organizational,
0:28:42.760,0:28:50.610
belonging to the ISP or infrastructure.[br]After we do that then we start sending all
0:28:50.610,0:28:57.980
our queries to these, let's say, open DNS-[br]resolvers in the ISP in Bahrain, for all
0:28:57.980,0:29:03.929
the domain we're interested. And capture[br]what we receive what IPs we receive. The
0:29:03.929,0:29:11.390
challenge is then to detect what is the[br]wrong answer. And so we have to come up
0:29:11.390,0:29:19.760
with a lot of heuristics. A set of[br]heuristics. For example the response that
0:29:19.760,0:29:28.610
we received is that equal to a reply we[br]got from our control measurements, where
0:29:28.610,0:29:36.500
we know the IP is not blocked or poisoned[br]or something. The content is there. Or we
0:29:36.500,0:29:42.060
can actually look at the IP that we[br]received and see whether it has a valid
0:29:42.060,0:29:50.850
http cert, with or without the SNI or[br]servername identification or something.
0:29:50.850,0:29:55.720
And so on so forth. So we come up with[br]lots of heuristics to detect wrong
0:29:55.720,0:30:06.840
answers. The results of all these efforts[br]ended up being a project called
0:30:06.840,0:30:12.210
"Satellite", which was started by Will[br]Scott. I'm sure he is in the audience
0:30:12.210,0:30:16.809
somewhere. A great friend of mine and very[br]good supporter of CensoredPlanet.
0:30:16.809,0:30:24.000
Selflessly, he has been a miracle that I I[br]had the opportunity and fortune to meet
0:30:24.000,0:30:31.890
him. We have Satellite. Satellite automate[br]the whole steps that I told you. For this
0:30:31.890,0:30:37.400
work we use science that developed in both[br]of the work. We call it Satellite because
0:30:37.400,0:30:46.421
of seniority and sticking with the name. So[br]how much coverage Satellite has? If you
0:30:46.421,0:30:54.880
scan IPv4 you end up with 4.2 million open[br]DNS-resolvers in every country in their
0:30:54.880,0:31:01.079
territories. We make, we need, we we[br]actually need to make sure there are
0:31:01.079,0:31:08.950
ethics for that reason. If we put a harsh[br]condition. We say that let's only use the
0:31:08.950,0:31:17.710
ones that fallow their valid PTR record[br]followed this expression. Basically let's
0:31:17.710,0:31:23.200
just use the open DNS-resolvers that are[br]name servers or at least their PDR record
0:31:23.200,0:31:29.920
suggests that. This is a really harsh[br]constraint. Actually, my students have
0:31:29.920,0:31:34.430
been adding more and more regular[br]expression for the ones that we are sure
0:31:34.430,0:31:42.610
they are organizational. But for now just[br]being this harsh we have 40k of DNS-
0:31:42.610,0:31:56.830
revolvers in almost 169 countries I guess.[br]So censorship happened in other layers as
0:31:56.830,0:32:00.700
well. How do we want to deal with that[br]remote channel, with the remote side
0:32:00.700,0:32:12.520
channel? And, especially, like, what about[br]http traffic or disruption that can happen
0:32:12.520,0:32:29.809
to you know TLS centric. I hate water.[br]Oh no. Okay. So. So it's scratching
0:32:29.809,0:32:38.220
noise it's well documented that many DPIs[br]especially in the Great Firewall of China monitor
0:32:38.220,0:32:43.930
the traffic and then they see a key word,[br]a sensitive keyword like "Falun Gong".
0:32:43.930,0:32:50.350
They act and a drop traffic or send a RST.[br]And as I mentioned earlier there are
0:32:50.350,0:32:57.330
enough clear text everywhere. Even in TLS[br]handshakes SNI is in clear text. And for a
0:32:57.330,0:33:03.590
long time I was trying to come up with a[br]way of detecting application layer using
0:33:03.590,0:33:09.320
this fancy side channel. Like, how can I[br]detect that when the client and server
0:33:09.320,0:33:14.630
need to first establish a TCP handshake,[br]how the side channel can jump in and then
0:33:14.630,0:33:22.720
detect the rest? We were lucky enough that[br]the end pointed to a protocol called
0:33:22.720,0:33:32.900
"Echo". It's a protocol designed in 1983[br]and it's for testing reasons, for the
0:33:32.900,0:33:41.140
debu..it is a debugging tool, basically.[br]It's a predecessor to ping. And basically,
0:33:41.140,0:33:50.120
after you establish a TCP handshake to[br]port 7, whatever you send the Echo servers
0:33:50.120,0:33:57.290
on port 7 it's gonna echo it back. Now[br]think about it. How we can use Echo
0:33:57.290,0:34:04.570
servers to be able to detect application[br]layer blocking? Well, when it's not
0:34:04.570,0:34:08.490
available, let's say I have an Echo server[br]in the U.S. and a measurement machine in
0:34:08.490,0:34:13.890
the University of Michigan I establish a[br]TCP handshake and I send a GET request
0:34:13.890,0:34:19.190
to... using a censored keyboard for[br]example. It's gonna get back to me the
0:34:19.190,0:34:28.269
same thing I sent. But now let's put the[br]DPI that is gonna be triggered by it.
0:34:28.269,0:34:37.150
Well, for sure, either I'm going to[br]receive a RST first or something else. So
0:34:37.150,0:34:43.609
we can actually come up with a algorithm[br]to be able to use Echo servers to detect
0:34:43.609,0:34:47.969
disruptions on application layer.[br]Basically keyboards blocking, URL
0:34:47.969,0:34:58.530
blocking. Results of this is a tool called[br]Quack. And Quack actually uses Echo
0:34:58.530,0:35:06.470
servers to be able to detect in a scalable[br]way and say if, whether the keywords are
0:35:06.470,0:35:14.380
being blocked around the world. So what[br]did we do is first scan the whole IPv4. We
0:35:14.380,0:35:22.910
find 47k Echo servers running around the[br]world. Then we need to be able to check
0:35:22.910,0:35:27.270
whether they or not belong to the end[br]users. And that was a very challenging
0:35:27.270,0:35:36.530
part because there is not a clear signal[br]as it's.. there are 90 percent of them are
0:35:36.530,0:35:40.730
infrastructure but there is still some[br]portion of them that we don't know. So
0:35:40.730,0:35:46.610
what we do is we look at the FreedomHouse[br]reports and the countries that are
0:35:46.610,0:35:52.931
partially open or not open, not free or[br]partially free what they're called. This
0:35:52.931,0:35:58.720
is around 50... This is around 50[br]countries. And for those we use... we
0:35:58.720,0:36:05.460
randomly select some that we want and we[br]use OS detection of Nmap. And if you have,
0:36:05.460,0:36:15.750
it will give us back it's a server, it's a[br]switch and so on. We use those. So with
0:36:15.750,0:36:23.010
the help of so many collaborators after[br]almost six years we end up with three
0:36:23.010,0:36:32.420
systems that can capture TCP/IP blocking,[br]DNS, and application layer blocking using
0:36:32.420,0:36:43.480
infrastructure and organizational[br]machines. So while it was, it was a dream
0:36:43.480,0:36:47.810
or a vision that we can come up with a[br]better map to collect this data in a
0:36:47.810,0:36:56.020
continuous way, thanks to help of a lot of[br]people especially my students, Will, and
0:36:56.020,0:37:02.060
other collaborators we now have[br]CensoredPlanet. CensoredPlanet collects
0:37:02.060,0:37:09.020
semi-weekly snapshots of Internet[br]censorship using our vantage point in all
0:37:09.020,0:37:18.090
the layers and provide this data in a raw[br]format now in our web site. We also
0:37:18.090,0:37:24.531
provide some visualization way for people[br]to be able to see how many vantage points
0:37:24.531,0:37:29.560
we have in each country and so on. Of[br]course, this is the beginning of
0:37:29.560,0:37:34.160
CensoredPlanet. We launched this at August[br]and we have been collecting data for
0:37:34.160,0:37:39.880
almost four months and we have a long way[br]to go. We have users right now through
0:37:39.880,0:37:45.130
organizations using our data and helping[br]us debug by finding things that doesn't
0:37:45.130,0:37:51.950
make sense pointing to us and any of you[br]that ended up using these data, please
0:37:51.950,0:37:56.930
share your feedback with us and we are[br]very responsive to be able to change it,
0:37:56.930,0:38:03.940
not as much as you need. They have a[br]collective of very well dedicated people
0:38:03.940,0:38:10.940
participating. So, now that we have this[br]CensoredPlanet let me give you how it can
0:38:10.940,0:38:19.349
help when there is a political situation[br]going on. You all must remember around
0:38:19.349,0:38:25.410
October there Jamal Khashoggi, a[br]Washington Post reporter, disappeared,
0:38:25.410,0:38:34.530
killed at the Saudi Arabian embassy in[br]Turkey. At the time of this happening
0:38:34.530,0:38:40.540
there was a lot of media attention and[br]this, this news especially two weeks in
0:38:40.540,0:38:46.980
become very internationally spread.[br]CensoredPlanet didn't know this event was
0:38:46.980,0:38:52.750
going to happen. So we have been[br]collecting this data semi-weekly for 2000
0:38:52.750,0:38:57.660
domain or so. And so we went back and we[br]checked the Saudi Arabia. Did we see
0:38:57.660,0:39:04.830
anything interesting? And yes, we saw for[br]example at two weeks in, around October
0:39:04.830,0:39:12.680
16, the domains that we were that was news[br]category and media category, the
0:39:12.680,0:39:18.500
censorship related to those doubled. And[br]let me emphasize, we didn't see like a
0:39:18.500,0:39:23.440
block or not block over the whole country[br]not all the countries have a homogeneous
0:39:23.440,0:39:28.430
censorship happening. We saw it in[br]multiple of the ISPs that we had vantage
0:39:28.430,0:39:34.770
point. Actually I freaked out when one of[br]the activists in Saudi Arabia told us that
0:39:34.770,0:39:41.869
"I don't see this". And we said "What ISP[br]you are in?" And this wasn't the ISPs that
0:39:41.869,0:39:49.160
we had vantage point in. So we were[br]looking for hints that "Is anybody else
0:39:49.160,0:39:55.720
seeing what we were seeing?". And so we[br]ended up seeing there was a commander
0:39:55.720,0:40:03.560
lab project that also saw around October[br]16 the number of malwares or whatever they
0:40:03.560,0:40:10.220
are testing is also doubled or tripled. I[br]don't know the other. So something was
0:40:10.220,0:40:17.180
going on two weeks in when the news broke.[br]Let me emphasize this news media that I am
0:40:17.180,0:40:22.300
talking about or the global news media[br]that we check like L.A. Times, Fox News
0:40:22.300,0:40:30.970
and so on. But we also checked Arab News[br]which is as the activists told us is a
0:40:30.970,0:40:38.490
Saudi Arabia's propaganda newspaper. That[br]in one of the ISPs was being poisoned. So
0:40:38.490,0:40:49.910
again, censorship measurement is very[br]complex problem. So where we're heading?
0:40:49.910,0:40:55.580
Well, having said that about side channels[br]and the techniques that help us remotely
0:40:55.580,0:41:01.900
collect this data I have to also say that[br]the data we collect doesn't replicate the
0:41:01.900,0:41:06.950
picture of the internet censorship. I mean[br]having a root access on a volunteers
0:41:06.950,0:41:17.641
machine to do a detailed test is powerful.[br]So in the next step, in the next year, one
0:41:17.641,0:41:27.720
of our goal is to join force with OONI to[br]integrate the data and from remote and
0:41:27.720,0:41:37.800
basically local measurements to provide[br]the best of both worlds. Also, we have
0:41:37.800,0:41:43.990
been thinking a lot about what would be a[br]good visualization tools that doesn't end
0:41:43.990,0:41:51.391
up to misrepresent internet censorship. I[br]literally hate that one. Hate it. The
0:41:51.391,0:41:56.860
number of vantage point in countries are[br]not equal. We don't know whether all the
0:41:56.860,0:42:00.980
vantage points that the data has resulted[br]from it is from one ISP or all of our
0:42:00.980,0:42:08.109
ISPs. And then we test domains that are[br]like benign and like I don't know defined
0:42:08.109,0:42:13.650
based on some western values of the[br]freedom of expression. I believe in all of
0:42:13.650,0:42:19.330
them but still culture, economy might play[br]something red. And then we put colors on
0:42:19.330,0:42:25.030
the map, rank the countries, call some[br]countries awful and not giving full
0:42:25.030,0:42:30.849
attention to the others. So something[br]needs to be changed and it's in our
0:42:30.849,0:42:37.700
horizon too. Think about it more deeper.[br]We want to be able to have more statistic
0:42:37.700,0:42:44.320
tools to be able to spot when the patterns[br]change. We want to be able to compare the
0:42:44.320,0:42:49.580
countries when for example Telegram was[br]being blocked at Russia. If you remember
0:42:49.580,0:42:54.910
millions of IPs being blocked. If you[br]don't, know go to my friend Leonid's talk
0:42:54.910,0:43:00.020
about Russia. You're going to learn a lot[br]there. But anyway. So when the Russia was
0:43:00.020,0:43:06.520
blocking Telegram, I said to everyone I[br]bet in the following some other
0:43:06.520,0:43:10.370
governments are going to jump to block[br]Telegram as well. And that's actually what
0:43:10.370,0:43:15.320
we heard, rumors like that. So we need to[br]be able to do that automatically. And
0:43:15.320,0:43:26.470
overall, I want to be able to develop an[br]empirical science of internet censorship
0:43:26.470,0:43:36.720
based on rich data with the help of all of[br]you. CensoredPlanet is now being
0:43:36.720,0:43:43.370
maintained by a group of dedicated[br]students, great friends that I have and
0:43:43.370,0:43:49.960
needs engineers and political scientists[br]to jump on our data and help us to bring
0:43:49.960,0:43:57.320
meaning to what we are collecting. So if[br]you are a good engineer or a political
0:43:57.320,0:44:07.250
scientist or a dedicated person who wants[br]to change the world, reach out to me. For
0:44:07.250,0:44:11.500
as a reference for those of you[br]interested: these are the publications
0:44:11.500,0:44:19.720
that my talk was based on.[br]And now I am open to questions.
0:44:19.720,0:44:26.180
applause
0:44:26.180,0:44:31.440
Herald: Allright, perfect. Thank you so[br]much, Roya, so far. We have some time for
0:44:31.440,0:44:35.500
questions so if you have a question in the[br]room please go to one of the room
0:44:35.500,0:44:40.100
microphones one, two, three, four, and[br]five in the very back. And if you're
0:44:40.100,0:44:44.490
watching the stream you can ask questions[br]to the signal angel via IRC or Twitter and
0:44:44.490,0:44:49.360
we'll also make sure to relay those to the[br]speaker and make sure those get asked. So
0:44:49.360,0:44:52.040
let's just go ahead and[br]start with Mic two please.
0:44:52.040,0:44:57.349
Question: Hey, great talk. Do you worry[br]that by publishing your methods as well as
0:44:57.349,0:45:02.690
your data that you're going to get a[br]response from governments that are
0:45:02.690,0:45:05.869
censoring things such that it makes it[br]more difficult for you to monitor what's
0:45:05.869,0:45:08.680
being censored? Or has[br]that already happened?
0:45:08.680,0:45:14.630
Roya: It hasn't happened. We have control[br]measures to be able to detect that. But
0:45:14.630,0:45:19.260
that has been... it's a really good[br]question and often comes up after I
0:45:19.260,0:45:25.490
present. I can tell you based on my[br]experience it's really hard to synchronize
0:45:25.490,0:45:31.490
all the ISPs in all the countries to act[br]to the SYN-ACK and RST that I'm sending.
0:45:31.490,0:45:36.150
Like, for example for Augur, this is[br]unsolicited packets and for governments to
0:45:36.150,0:45:41.850
block that they are going to be a lot of[br]collateral damage. You might say that
0:45:41.850,0:45:45.610
well, Roya, they're going to block the IP[br]of the University of Michigan. They're a
0:45:45.610,0:45:50.770
spoofing machine. We have a measure for[br]that. I have multiple places that I
0:45:50.770,0:45:56.190
actually have a backup if that case[br]happened. But overall this is a global
0:45:56.190,0:46:02.800
scale measurement, and even in one city or[br]like multiple ISPs you know of it's really
0:46:02.800,0:46:06.920
hard to synchronize being like blocking[br]something and maintaining. So it is
0:46:06.920,0:46:13.630
something that's in our mind thinking[br]about. But as as of now it's not a worry.
0:46:13.630,0:46:16.470
Herald: All right then let's[br]go over to Mic one.
0:46:16.470,0:46:20.510
Question: Thank you. I wondered, it's kind[br]of similar to this question. What if you
0:46:20.510,0:46:24.920
are measuring from a country that is[br]blocking? Do you also distribute the
0:46:24.920,0:46:29.970
measurements over several countries?[br]Roya: Absolutely. Every snapshot that we
0:46:29.970,0:46:37.280
collect is from all the vantage point we[br]have in like certain countries and portion
0:46:37.280,0:46:42.100
of vantage point in like China or like US[br]because they have millions of vantage
0:46:42.100,0:46:46.220
points or like thousands of vantage[br]points. So basically at each snapshot,
0:46:46.220,0:46:52.340
which takes us three days, we collect the[br]data from all of all of the vantage point.
0:46:52.340,0:46:57.580
And so let's say that somebody is reacting[br]to us. We have a benign domain that we
0:46:57.580,0:47:03.250
check as well like for example a domain[br]example.com or random.com. So if we see
0:47:03.250,0:47:09.380
something going on there we actually[br]double check. But good point, because now
0:47:09.380,0:47:14.720
our efforts is very manual labor and we're[br]trying to automate everything so it's
0:47:14.720,0:47:18.900
still a challenge. Thank you.[br]Herald: All right then let's go to Mic
0:47:18.900,0:47:22.859
three.[br]Question: Hi. Have you measured how much
0:47:22.859,0:47:28.140
does IP-ID randomization[br]break your probes?
0:47:28.140,0:47:35.349
Roya: Oh. This is also really good. Let me[br]give a shout out to [name]. He's the guy
0:47:35.349,0:47:45.990
at 1998 discovered IP-ID or published[br]something that I ended up reading. So like
0:47:45.990,0:47:54.440
for example Linux or Ubuntu in the U.S.[br]version they randomized it but it still
0:47:54.440,0:47:59.421
draws this legacy operating system like[br]WindowsXP and predecessors and FreeBSD
0:47:59.421,0:48:04.750
that still have global IP-ID. So one[br]argument that often come up is, what if
0:48:04.750,0:48:09.339
all these machines get updated to the new[br]operating system where it doesn't have a
0:48:09.339,0:48:13.780
maintain global IP-ID? And I can tell you[br]that, well, we'll come up with another
0:48:13.780,0:48:20.129
side channel. For now, that works. But my[br]gut feeling is that if it didn't change
0:48:20.129,0:48:25.230
from 1998 until now with all the things[br]that everybody says that global IP-ID
0:48:25.230,0:48:30.440
variable is a horrible idea, it's not going[br]to change in the coming five years so
0:48:30.440,0:48:33.230
we're good.[br]Question: Thank you.
0:48:33.230,0:48:36.520
Herald: Okay, then let's just[br]move on to Mic four.
0:48:36.520,0:48:41.480
Question: Thank you very much for the[br]great talk. When you were introducing
0:48:41.480,0:48:46.910
Augur I was wondering, does the detection[br]of the blockage between client server
0:48:46.910,0:48:52.190
necessarily indicate censorship? So,[br]because you were talking about validating
0:48:52.190,0:48:59.130
Augur I was wondering if it turns out that[br]there is like a false alarm. What do you
0:48:59.130,0:49:04.530
think could be the potential cause?[br]Roya: You're absolutely right. And I tried
0:49:04.530,0:49:11.630
to emphasize on that that what we end up[br]collecting is can be seen as a disruption.
0:49:11.630,0:49:17.200
Something didn't work. The SYN-ACK or RST[br]got disrupted. Is that there is a
0:49:17.200,0:49:22.250
censorship or it can be a random packet[br]drop. And the way to be able to establish
0:49:22.250,0:49:28.290
that confidence is to check whether[br]aggregate the results. Do we see this
0:49:28.290,0:49:33.670
blocking between multiple of the routers[br]within that country or within that AS .
0:49:33.670,0:49:38.880
Because if one of this is for accident[br]that just didn't make sense or didn't get
0:49:38.880,0:49:43.900
dropped, what about the others? So the[br]whole idea and this is another point that
0:49:43.900,0:49:50.390
I'm so so concerned about: Most of this[br]report and anecdotes that we read is based
0:49:50.390,0:49:55.869
on one VPN or one man touch points in the[br]country. And then there are a lot of lot
0:49:55.869,0:50:00.770
of conclusion out of that. And you often[br]can ask that well this vantage point might
0:50:00.770,0:50:05.640
be subject to so many different things[br]than a government's censorship. Also I
0:50:05.640,0:50:11.980
emphasized that the censorship that I use[br]in this talk is any action that stops
0:50:11.980,0:50:17.180
users' access to get to the requested[br]content. I'm trying to get away from a
0:50:17.180,0:50:23.480
semantic where of the intention applied.[br]But great question.
0:50:23.480,0:50:26.240
Herald: All right, then let's go back to[br]Mic one right.
0:50:26.240,0:50:29.740
Question: Hi Roya. You mentioned that you[br]have a team of students working on all of
0:50:29.740,0:50:33.890
these frameworks. I was wondering if your[br]frameworks were open source are available
0:50:33.890,0:50:37.760
online for collaboration? And if so, where[br]those resources would be?
0:50:37.760,0:50:45.040
Roya: So the data is open. The code hasn't[br]been. For one reason is I'm so low
0:50:45.040,0:50:49.090
confident in sharing code, like I'm[br]friends with Philipp Winter, Dave Fifield.
0:50:49.090,0:50:54.170
These people are pro open source and they[br]constantly blame me for not. But it really
0:50:54.170,0:51:00.721
requires confidence to share code. So we[br]are working on that at least for Quack. I
0:51:00.721,0:51:06.390
think the code is very easily can be[br]shared. For Augur, we spent a heck amount
0:51:06.390,0:51:12.109
of time to make a production ready code[br]and for Satellite I think that is also
0:51:12.109,0:51:17.420
ready. I can share them personally with[br]you but before sharing to the world I want
0:51:17.420,0:51:21.560
to actually give another person to audit[br]and make sure we're not using a curse word
0:51:21.560,0:51:26.420
or something. I don't know. It's just[br]completely my mind being a little bit
0:51:26.420,0:51:31.030
conservative. But happy if you send me an[br]e-mail I send you to code.
0:51:31.030,0:51:35.640
Question: Thank you.[br]Herald: All right then move to Mic two.
0:51:35.640,0:51:39.930
Question: Thanks again for sharing your[br]great vision. I find it really
0:51:39.930,0:51:47.470
fascinating. Also I'm not really a data[br]scientist but my question is: did you find
0:51:47.470,0:51:56.099
any any usefulness in your approaches in[br]the spreading of the Internet of Things? I
0:51:56.099,0:52:06.960
understood that you used routers to make[br]queries but did you send and maybe receive
0:52:06.960,0:52:11.260
back any data from[br]washing machines, toasters,...?
0:52:11.260,0:52:17.480
Roya: I mean, I know, being ethical and[br]trying to not use end user machine limits
0:52:17.480,0:52:22.589
your access a lot. And but but but that's[br]our goal. We are going to stick with
0:52:22.589,0:52:28.240
things that don't belong to the end users.[br]And so it's all routers, organizational
0:52:28.240,0:52:31.940
machines. So I want to make sure that[br]whatever we're using belong to the
0:52:31.940,0:52:35.349
identity that can protect themselves if[br]something went wrong. They can just say
0:52:35.349,0:52:39.640
"Hey this is a freaking router, it[br]receives and sends so many things. I mean,
0:52:39.640,0:52:44.740
look, let me give you show you a TCP (?),[br]for example. A volunteer might not be able
0:52:44.740,0:52:49.290
to defend that because it's already[br]conspiring and collecting this data. But
0:52:49.290,0:52:53.550
good questions, I wish I could[br]but I won't pass that line.
0:52:53.550,0:52:57.380
Herald: All right. I don't see any more[br]questions in the room right now. But we
0:52:57.380,0:53:01.080
have one from the internet[br]so please, signal angel.
0:53:01.080,0:53:06.510
Signal Angel: Yes. Actually a question[br]from koli585: I was in an African
0:53:06.510,0:53:10.009
country where the internet has been[br]completely shut down. How can I quickly
0:53:10.009,0:53:14.709
and safely inform others[br]about the shut down?
0:53:14.709,0:53:21.470
Roya: So while I think local users' values[br]are highly highly needed they can use
0:53:21.470,0:53:27.510
social media like Twitter to send and say[br]whatever, there is a project called IODA.
0:53:27.510,0:53:36.869
It's a project at CAIDA UCSD University in[br]U.S. and Philipp Winter, Alberto
0:53:36.869,0:53:43.160
[Dainotti] and Alistair [King] are working[br]on that. They basically remotely keep
0:53:43.160,0:53:51.540
track of shutdowns and push them out. If[br]you look at the IODA on Twitter you can
0:53:51.540,0:54:02.620
see their live feed of how the shutdowns[br]where the shutdowns happen. So I haven't
0:54:02.620,0:54:09.260
thought about how to reach to the users[br]telling them what we see or how we can
0:54:09.260,0:54:18.609
incorporate the users' feedback. We are[br]working with a group of researchers that
0:54:18.609,0:54:27.000
already developed tools to receive this[br]data from Tweeters and basically use that
0:54:27.000,0:54:31.890
as some level of ground truth, but OONI[br]does such a great job that I haven't felt
0:54:31.890,0:54:37.220
a need.[br]Herald: Alright. Unless the signal angel
0:54:37.220,0:54:43.750
has another question? No?[br]Roya: And let me, can I add one thing? So
0:54:43.750,0:54:52.940
I was listening to a talk about how[br]Iranian versus Arabs were sympathetic
0:54:52.940,0:55:01.040
towards Boston bombing in United States[br]and there were a lot of assumptions and a
0:55:01.040,0:55:05.819
lot of conclusions were made that, oh[br]this, I'm completely paraphrasing. I don't
0:55:05.819,0:55:09.900
remember. But this Iranian doesn't care[br]because they didn't tweet as much. So
0:55:09.900,0:55:17.060
basically their input data was a bunch of[br]tweets around the time of Boston bombing.
0:55:17.060,0:55:21.599
After the talk was over I said: you know[br]that in this country Twitter has been
0:55:21.599,0:55:28.929
blocked and so many people couldn't tweet.[br]applause
0:55:28.929,0:55:33.490
Herald: Alright. That concludes our Q&A,[br]so thanks so much Roya.
0:55:33.490,0:55:35.436
Roya: Thank you.
0:55:35.436,0:55:41.150
applause
0:55:41.150,0:55:45.970
postroll music
0:55:45.970,0:56:04.000
Subtitles created by c3subtitles.de[br]in the year 2020. Join, and help us!