Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/2570 Thanks!
[Music]
good
evening
hello good evening hello welcome to
Millie Bo and the
evening the evening talks at mway uh on
day three I hope you had a great day
already and we'll have a much greater
day even in the evening today with uh
nice talks um the
next the next talk will be held by the
network team of the tour project and
they will present us uh with a guided
tour through tour networking health and
[Applause]
performance thanks everybody for coming
um we have collected a little group of
people from the tour project here who's
going to talk a bit about General
Network status thing and particularly
will focus on the health and the
performance that we've been working a
lot on in uh in the past few years so
I'll just do a quick introduction of
everybody I'm Alex I'm heading up tours
Network team we're the team responsible
for writing the SE tour implementation
and the rust implementation that we'll
be talking a little bit about called
Arty um then we also have Yuga on stage
Yuga is one of our bandwidth scanning
experts and work together with G who is
the Network Health Team lead um finally
we have Gus who is uh heading up our
community team and is uh doing a lot of
the engagement with people in our
community and the relay operating
community and so forth so if we start
out with talking a bit about some of the
features we've been working on for uh
the currently stable Tour release called
047 one of the things we built in that
was congestion control tour had
originally not had any sort of good
mechanisms like we see in TCP with the
with regards to congestion control and
handling congestion in the network which
led to um a higher variance in sort of
error conditions when um when um when
you were using tour and the the
performance was uh not so good so what
the team did was that we evaluated a
number of different options for
congestion control algorithm people who
are into some of these TCP things will
might not notice some of the names are
similar they're very related from from
sort of the general Network World um
the3 uh system we looked at was called
Westwood and Vegas and Nola um while the
team was looking at it Google also came
with a paper with a congestion control
system called bbr but many of these
systems suffered from some issues that
led to these runaway congestion
conditions which made them unsuitable
for what we were trying to do we um we
ended up uh spending a lot of time uh
working in a simulator that we have
called shadow where we tried to test the
different algorithms for seeing how they
were performing having an idea about
which parameters we could tune in
various conditions and see how things
are doing these plots are a little bit
difficult to understand they're CDF
plots but uh the idea here is that the
uh orange part of the curve is um is the
047 release and the blue part is the 046
release and um the left picture is a
simulated instance where we try to
behave like where client being in
Germany and on the right hand side we
see one in Hong Kong and what basically
these things tell is that we see a
higher amount of the traffic being um
being performant for for the new
system in um we are sort of moving
towards this new release that are coming
very soon uh where we have then decided
to remove some of these algorithms
because they're simply unused and Vegas
is the only one currently that is
left we will continue to tune on these
things we will learn as as more clients
are coming on as we do various upgrades
in the network so we would likely have
to tune different parameters and the
entire system is made so that the
directory authorities which is the notes
that are sort of the trust anger in the
tour system will be able to tune certain
parameters based on various like ideas
or experiments we want to try
out so all of this sounds good and many
people will sort of say okay is it then
going to be super performant or how is
it actually going to going to change
things as some of you may know we have
had a denial of service going on on the
network for for quite a a while so uh
I'm trying to show this using some
fairly old plots um and then show it
with some very current uh plots after
the network has upgraded to to the
047 so if you look at this one this is
uh the time to complete a 5 megabyte
download to a public server over the
tour Network as you can see the variance
is very very high in this we have some
error conditions where it took up to 50
seconds for for for sort of these
requests to go through and most likely
the user will have abandoned the web
request that was happening there so
after we deployed congestion control it
now looks like this we're down to having
sort of a 20 second boundary on this and
it's starting to look a whole lot better
and you will likely also experience this
when you're using tour browser in your
daily life uh because ideally the
request should go through quickly
right I believe there's a lot of you in
this room uh or in this on this stage
that uh is operating uh tour relays a
massive thank you to to everybody who
upgraded to 047 very very very quickly
yes big round of applause for
that it is so important that when we get
releases out that they get deployed to
the network because many of the releases
that we make requires us to upgrade the
network before we can start upgrading
the clients so before we can start
including these features in for example
tour browser or other applications that
uses tour then we need the network to be
upgraded so huge thanks to everybody who
is uh who's been doing
this
we um I think last week I've been
camping for a while but last week we
released the uh release candidate for
the tour
048 just like with 047 which had the
congestion control feature there's some
pretty important features that I'll be
talking about in a moment which uh which
is coming out in this release so we
really hope that people will be very
very Snappy with upgrading uh quickly
again so we can start testing these
things out on the on the live
Network so one of the big features that
we are adding in 048 is very much
related to this denial of service
attacks that we've seen um the the
nature of the denial of service attack
is not so that there is one denial of
service attacks we've likely seen many
different kinds of attacks that's
happening within the network but sort of
because of the design and tour we can't
really go in and say and pinpoint what
exactly is happening but we know that
some of the attacks is happening towards
onion service traffic which means that
it stays within the network and never
goes out over the exit nodes so one
thing we've implemented is that we have
implemented a proof of work scheme um
some of you know these from uh from
blockchain projects and how they are uh
burning down our planet um this uh this
system is designed in a way so that by
default it's not enabled but the onion
service if it U sort of realizes that
it's under attack on various Network
condition seems bad it can enable it and
slowly sort of increase the uh increase
the sort of difficulty that is used for
clients to to to connect we have uh
chosen a scheme that we got uh help from
from a country contributor called
tivador great thanks to to them for
working on this if you interested in
sort of the technical details about how
this scheme works we have this proposal
called uh 327 which includes uh all the
technical aspects for how to implement
it and as of last week I believe uh we
also have the documentation ready if you
are operating onion services for how to
uh how to use this feature and and
testing it out in your production
system
um there is uh one slight catch with the
with this uh proof of work scheme it
uses quite a lot of memory which means
that particularly for Apple's very
closed iOS platform we are likely not
going to be able to enable it um it's
Guardian Project who's doing the Orbot
for iOS and because of uh Apple's
Network extension memory limits we are
very unlikely to be able to support it
there but the effect will likely be the
same as if the feature was not there
namely that if there is an error
condition happening for the uh for the
given onion service then decline will
simply not be be able to reach it and
this will just impact iOS users more if
you know anybody who works for Apple
then please ask them to bump this limit
uh it has been bummed a few times but
it's still a bit uh bit too low for us
at
least the uh the big feature that is
going to come in 048 is a feature called
conflux historically uh most people in
here is probably aware of that uh when
you have a torrent circuit you have a
decline which connects to a guard node
and you extend it to a middle node and
then finally to an exit node where you
then make your TCP flows out to the
internet one of the um API features that
we have now inside of tour from the
congestion control system is that we can
get information while the traffic is
being sent and received on how congested
the link is this allows us to utilize
this conflux feature to create multiple
legs into the network and um sort of
rendevu at the exit node and then the
client can learn which of these two
paths through the network is the least
congested and switch over to transmit
and receive on that one so hopefully now
that we have seen with the congestion
control part that we have gotten the
variance of errors and delays down then
we hope with conflux we'll see sort of a
greater performance when you're when
you're downloading larger things and and
using the Detro Network in
general one of the um really nice thing
was sort of uh this whole performance
project we've been running in the
network team for a while now has been
sort of how the team has been working
together and developing things we have
historically used this tool called
chopne it's sort of a little python
thing where you can uh say give me a Tor
Network with 400 notes and it then
starts 400 tour instances on your
computer and you can test things we also
have a system called Shadow which is a
like um a more powerful simulator where
you can sort of simulate a whole tour
Network and including having time change
so we can for example simulate a Year's
use of of the chor system over over like
a couple of hours and we can even do it
in our CI tool chain which has been uh
really really
awesome um one really nice thing with
sort of how we work we work like many uh
many research projects so we get grants
to do our work we um often these denial
of service conditions that happens have
this impact that we need to drop
everything we're currently doing of
deliverables and switch over to doing uh
like mitigating the attacks we
fortunately now have a sponsor um where
we can uh do some of this work on denial
of service if something comes up and if
we need to tune things or if we need to
come up with new mitigation techniques
for people who are sort of nerding out
on our gitlab then these things are
tracked as uh like gitlab has this label
thing and we have a denial of service
label and we also have a sponsor 112 So
if people are interested in seeing what
kind of things we are are planning you
can go look
there how many people in here have heard
of uh
Ry okay not so many um is our attempt uh
hopefully it's going to be successful
with trying to write a rust
implementation of tour that will
eventually replace the C
implementation one of the issues that
exist with the seor is it it's a very
old application by now that has sort of
evolved over time it the the
architecture of it is not really fit for
sort of the modern day world with how we
do applications how we have mobile
applications and so on so R will become
a uh primarily an API for working with
different kind of tour objects like our
D Network documents and making circuits
and these kind of things um and it will
eventually allow you to both build a
tour binary like you're used to having
today where you can connect over a sock
Port but it will also allow you to have
a tour implementation embedded into your
applications if you want to do certain
things um and finally it will also of
course support onion
Services we um it it's it's not an a
sort of an easy decision to to make that
you want to rewrite like throw away so
many years of of of work and then try to
rewrite it in another language we uh do
some assessment on our uh uh issues when
we have issues that we consider that
they have such severity that they would
be considered security bugs and we could
see at some point that 21 out of 34 of
what we call troves they are bit like
our internal cves where we have some
different categories that we use uh
would be highly unlikely to to happen if
we were using more memory save languages
such as rust another big component of
this is that the network teamour is much
more excited about rust than they are
with with c and developer happiness is
is fairly important as
well if we look a bit at um the uh the
road map for R um we are now at the
point where we are working on onion
Services we've just entered the year 2
funding for this um there's already
stuff that uh if people want to try
around around with having sort of a
little rust Library where you can build
onion Services then you can start trying
it out today uh the goal is that when we
are at the end of this year the browser
team atour will be start uh to be able
to play around with embedding Rd into
the uh into the
browser we are currently working on
getting funding for building um relays
and bridges and directory authorities
and all these sort of things that are
hosting the network but for now we are
sort of focusing on the client side
because the way tour is designed the
client side is sort of the diff thing to
build right now it's um almost the
majority of the network team atour is is
working on RD or Rd related deliverables
we also have a little VPN project that
we're experimenting with that uh that is
also getting some
attention we hope to uh very soon have
sort of the entire team focusing on this
we're currently three people out of 10 I
think that is sort of left focusing on
on seor what you will most likely see is
that we will start limiting client
features so only do the things that is
needed to upgrade the network and then
do the um do the client features
primarily in um in in Rd itself one of
the big things we want to work on soon
is uh UDP for example UDP will have a
network upgrade in the c tour
implementation and then it will have
feature support uh client feature
support only existing in Rd we will of
course continue to support c tour for
until we're ready to replace it it would
be crazy to do anything
else if you're interested in tracking
some of these uh engineering efforts
that we're doing um I believe that U one
of the nice thing we have with Rd is
that it will probably be easier for for
more people such as yourself to
contribute uh the c tour code base was a
bit difficult to get uh sort of wrap
your head around when you're just diving
into it we have an IRC channel tev on of
on the ofc network and we also map it
over to uh to Matrix as tev we have our
gitlab uh account uh well our gitlab
instance where you can attract Le
engineering efforts and what we're doing
and so on if any of you are interested
in this you're also welcome to come and
find me here at camp and and talk a bit
about these
things now I'm going to pass the mic to
Yuka who's going to talk a bit about
bandwidth
[Applause]
scanning so bang with the scanner um we
need them to monitor the T Network
performance to better distribute the
load across the network and to help to
verify relays bandwidth because the
relays themselves report the bandwidth
they see that pass through them but uh
there are no other relays to verify them
to verify that so how it was um uh the
scanner build two hop circuits between
the relay that wants to measure and
another relay that uh helped to measure
this relay with double bandwidth
um then download uh data through this
circuit and write it in a file uh every
hour the this file is read by the
director authorities and they vote on
the consensus
way this is a graph of the number of Rel
H measures by the bang with the scanner
by each directory Authority in the last
four
days uh what is new now is that we have
also a bridge scanner the bridge scanner
was in a very similar way but it creates
uh three hops
circuit
and this helps with the uh users to have
a better experience because now instead
of just Distributing the bridges that
are available the bridge Authority is
Distributing the bridges that which bang
with thol bang with ratio is over a
certain
thol and this is a graph about the
measur bridges in the last
days uh the ones that were accepted over
that ratio and the ones that are
not oh um and then gecko is going to
talk about more Network Health
things
thanks looks good
thanks all right so you you heard
already from Alex and Huga a lot about
the performance angle of Network Health
work but as you might know um there are
many more things we have to consider um
once we want to think about whether a
network is in a healthy state or not so
we have a project Alex has been
mentioning already which we are
currently focused on which is trying to
defend more um effectively against
malicious relays which is a um
considerable issue for the torenberg for
a long time you might have heard about
this you can see the nitty cre details
in the blog post I wrote um a while ago
but but having malicious relays on
network is definitely not good for the
health of the network overall so what we
want to do is um um improving the the
state of the uh of the art uh which is
currently um yeah deployed and which we
currently have as tools um but that's
only one of the things which needs um
improvements because as we have seen um
over the years of fighting malicious
relays just um setting on and on having
more and more sophisticated tools to
find and hunt down and and kick out
malicious relay is not is not going to
fly over the long run there's no way to
win to win this arms race in that way um
we have to have a um a kind of a social
approach as well um a different tool in
our tool chain for for for defending
against just Rel is that way guess we
talk um a bit about that what we have in
in mind and what we plan in the next
couple of of weeks and month um but that
that's is an important thing to keep in
mind there's no technical Only Solution
against malicious relays in the uh in
the tow Network and we are working on on
that part getting this right
um and the other important point when
you're thinking about Network Health is
that there are a lot of relays attack
relay attacks which we have seen oh
sorry which we have seen um over time
over the years in in practice and in
mentioned in papers we never found time
to actually address those um in uh in
our day-to-day Works um we got funding
for that um I talk a bit later about
what those attacks are we have in mind
um Alex mentioned already one which is
Dos one which is a really hard one um
because we have seen um in the uh in
this year DS attacks which were kind of
four different DS attacks coming to the
network at the same time and all four of
them would have um needed totally
different approaches to tackle them one
Alex mentioned already the proof of work
thing and there are other ones but we we
want to make progress on those things as
well in the uh in this upcoming work and
the timeline for the project was um
October 22 to October 24 that we are
kind of in the middle of where we um um
where we are where the work on on this
part um we have actually to dig a bit
deeper it's not just um fixing you know
tools for detecting malicious relays or
fixing those attacks we have to redo our
Matrix pipeline as well the reason for
that is
um it's not as I said it's not really
enough to have you know tools for
detecting malicious relays and then
kicking them out sometimes we have seen
really persistent attackers in the
network um doing attacks over month and
and sometimes one or two years so and we
need to detect those things earlier and
and we need to do those uh detections by
by not having only compressed tobl um of
descriptors and consensuses and whatnot
over over month and years as we have it
now because that's really Compass arm to
work with and slowing things down so
what we want to do is um we want to redo
our metrix pipeline uh in a way um as
you can see on on this picture here so
we have a a downloader um which is
downloading all the the different
descriptors and then macro descriptors
and consensuses and it's it's writing
things in an archive and at the same
time it's putting things in a postrest
uh ql database and then a Victoria
metrix um piece which is is helping with
a Time series and then we want to do a
um restful API written in Rust where we
can query stuff and having some shiny
crana dashboards where you can easily
see how things are going on this is um
not just meant to be for our internal
usage but of course at the first um time
we will be the the ones dug footing our
stuff but they we we plan to somehow
expose this to uh to interested
operators and The Wider Community as
well can um dig through the data and uh
come up with issues in the network we
might not see and uh just play with
stuff around at at some some point later
we'll see how this goes um at the second
um point we want to do um while we are
working on this project in the metrix
area is we want to build a small um
service to annotate our um knowledge of
the tour Network and this tool is called
tag tour and it's basically like a relay
search we have right now if you go to
matrix. tour project.org there's a an
option to to look at the uh state of
your relays via relay search and what we
want to do here is we um want to like to
to add a little no or category to tour
routers um where we can keep um State
kind of state of tour routers uh which
would for instance say hey maybe Gus
knows the operator or maybe I am knowing
the operator maybe R knows the operator
and um and maybe you can annotate and
say hey I've met this guy at at the camp
or at the at dcon or whatever so we can
see a bit um first how how many of The
Operators we actually know because
nobody is knowing this nowadays and then
we can ask you know I know these these
number of operators then we can think
about hey how many uh of the of the
capacity of the network do I actually
know you know by operators this kind of
stuff and and this allows us later on to
build actually tools for our bed relay
work on top of that gu we mentioned some
of those um one one thing that got
mentioned the past is we could say okay
in order to minimize the risk for for
our users we could just cap the um the
the total amount of exit capacity a
single operator can can run in the
network right now it's not really a
thing embedded in the code it's it's
kind of um operators contacting us and
saying hey I'm now running 10 % of the
exit capacity is that okay or should I
maybe do something else because it might
be exposing too much risk to to your
users and um but then we could think
about building is a thing where we say
okay maybe it's just allowed uh to for
exit operators to run 5% of the exit
capacity or maybe just 10 or whatever U
but first of all we need to know how
many of those folks we actually know to
have a um an idea of um how many people
we trust in the network by now
so for the really attacks here are some
of the things we we could think about
and we are actually thinking about you
can find more details um in this gitlab
Milestone where we have a detailed
description of the things we want to
work on and measuring those attacks
there are really side Channel attacks we
have seen in the past U where users um
got de anonymized we want to investigate
and finally fix taging attacks um where
we try to to uh to uh manipulate the
routes of the network users can use uh
not we but attackers um can use and we
try to defense against that and do Texs
already got mentioned we have some some
traffic analysis papers resistance
papers seen in the past and we we want
to implement the most um um promising
things from them into these uh into the
code we have and then there are bandwith
inflation attacks uh you might recall um
hook are talking about the bandwith
scanner one of the ideas was at some
point building a bandwidth scanner which
is um actually not really only measuring
the bandwidth um but detecting um once
relays try to um claim they are able to
relay more traffic than they actually
are um because there might be people
around saying oh I I just you know set
up this relay and um and whenever a user
is coming I just um give it a really
crappy service um trying to to minimize
the cost I have for running a relay but
once the bandwidth scanner is coming and
measuring my relay I really I show there
as a really big bandwidth I have
available and that's why I get um a
higher consensus rate which means more
users are picking my router in the in
the circuit uh and this kind of of of
cheating and attacking the network we
want to avoid at some point and there
are ways we can do that actually and uh
we are working in in in this project uh
moving forward in this
direction so I think um that's it for me
I pass the the mic to Gus for the final
por hello uh so this is a t isit node
that is hosted here in CC Camp thanks uh
uh article 10 for her running this relay
so
so I'm going to talk a little bit about
the work that the T Community team is
doing uh first thing that we need to
acknowledge is that um Tor as an
organization we develop the the software
and as you see uh Alex talking about the
complex stuff about conflct congestion
control algorith algorithms uh Geo and H
got talking about Network Health
but there is one very important
component that is the community who's
running the software like without relay
operators we don't have tar Network or
we don't have tar right so uh the idea
of the of this um to mitigate the
attacks against T the ideas to improve
the Network Health um the community
health uh of the tar
Network so we talked before uh on
building tools uh to fight bad relays
like creating scanners and this kind of
stuff this is one way to fight bad
relays but the other way is also using
the social approach so instead of
running scanners this is also we are
going to do but the idea is to have a
community that we know so we can say oh
this person that is running one 100
relays we know them and they are cool
people uh so uh the idea is to make the
community harder for
infiltration uh so one quick question uh
please hide your hand if you're running
a thir
node okay I can see some
people uh so according to our specialist
on Twitter call it x uh Brew the NSA
control a significant amount of t as it
nodes something like 90% I don't know
how accurate is this I love the day I
heard the they steps nothing is truly
safe so according to this random person
on the internet 90% of people here are
paid or are part of NSA right and this
is ridiculous so we can see part of the
Network Health discussion on the
Internet is very low like uh they people
do randomly do claims about uh who is
running T and just something that we
want to change not about their
reputation but also about um uh also
about like uh knowing the community and
showing the work that people are doing
is also rewarding like people can when
to be seeing like hey I'm contributing
with the tar Network 10% of the exit
capacity or uh 15% of theit capacity and
this is very important you
know uh so there are many adversaries
against star but there are I I believe
there are two extreme positions that are
not helpful on this debate one is
underestimating the problem like well
everything's fine please don't remove my
super sketch relays uh they are just
happy relays so we have this kind of
actitude and the other one is like a
overestimation of the problem like oh
the CIA is running the whole T Network
so I'm going to use this other solution
here instead of the T Network and this
obvious uh doesn't uh a good solution
right so uh one thing that we have been
working uh to mitigate this problem of
uh thrust on the T network is to create
a process uh involving the relay
operators um
when hello hello is
working hello
okay so uh we have a a process uh
involving the the T community so uh the
idea is to have relay operators to
submit proposals or ideas or comments or
suggestions how we can improve the Tor
Network and how we can improve the the
health of the Tor Network uh we wrote
very recently A A meta policy where you
can understand how is the process how
you can submit a proposal to to improve
the Tor Network
Health so some examples of proposals
first thing uh first example a guideline
for maximum consensus that Geo was
talking here uh other thing was
um allowing uh allow a limit total
consensus as a fraction by by family so
if you are running a family of asit no
you can only run 10% of theit capacity
no matter what if you add 100 more
relays it will always be the same this
is a proposal is not approved we are
evaluating this kind of ideas um and
also we have another proposal like um
another example of proposal of how you
can conduct open source investigation
when you're hunting malal relays so one
thing one problem that we sometimes we
have people report uh that are relay is
bad but when we ask them like okay how
that relay is bad what they are doing uh
the person doesn't explain how they came
up with that result so if we cannot
reproduce that thing we cannot say
that's a bad relay right and uh and if
you look on for example in in Twitter
and social media and other places you
can see like sometimes people saying
crazy stuff about exit noes or relays
saying like uh well this as it know is
clearly malicious because you can see by
the contact info and sometimes Rel
operators are very uh funny people uh
they sometimes create names of their
associations as CIA about confidential
integrity and
authentication so uh sometimes people
are very funny and and you users are not
they don't think that's a funny thing so
um this is um this is why we a guideline
to have a to help people to do open
source investigation so uh because door
network is a public network we should
expect that people are checking uh their
relays right uh and see the the behavior
of this
relays uh another example of a proposal
that was recently submitted from the
community like uh we have a limit
of uh how many relays you can run by
ipv4 so before was true uh and the idea
was you cannot run with one single ipv4
address you cannot run 1,000 relays So
to avoid this kind of attack it was
limit limited to two uh we bumped that
number to four because some relay
operators wrote a very nice proposal
saying hey the ipv4 is very expensive
and we have Hardware we have Capac we
have bandwidth the only thing that we
don't have and very expensive is to buy
a pv4 so the idea was okay we can bump
too far and see how the attackers are
going to uh uh act what's the their
behavior if everything's fine we can
bump to eight so right now you can see
that we have uh you can run eight relays
per
ipv4 um and that can that created a very
interesting graphic here you can see
that before this proposal
we were like 100 uh 1,500 relets as it
no sorry uh and now after this proposal
was approved we have now almost 2,500
rels so this is how a policy made by the
community and endorsed by and enforced
by the T project just how we can change
the T Network right so sometimes we
believe oh how we are going to increase
the T netor capacity or how are we going
to make uh more people to collaborate
or make the T Network faster sometimes
is a not an engineer thing but also a
policy thing like a something that
something that we can change on the T
codes something we can change on the tar
network uh so the next activities that
we have here in the camp uh tomorrow we
have the T Relay operator Meetup uh you
don't need to be running relay to join
just Meetup if you are interested on T
if you have questions about t or is
snowflake or other plugable transport
that we didn't talk about that today
well you are welcome to come and and ask
about this is going to be on barnack
Village at 4 pm and um you can also
check this very cool project from
article 10 on their Village I don't know
how to pronounce German so I'm not going
to direct to pronounce this um and you
can check their exit noes on on and make
questions like uh article 10 is one of
the top one of the largest uh isit
operate
operators uh on the T Network so if you
are think like oh NSA is running a bunch
of relays actually it's probably article
10 nothing to hide that's the operator
for Netherlands uh many other operators
here in Germany so you have opportunity
here to I believe meet 40% of the t Exit
capacity so if you walk around and talk
with people you are running the T
Network
and and uh and we have the uh another
campaign happening uh with electronic
front foundation called the Tor
University challenge it's University but
means education so if you have a school
if you have a education project you can
join this uh challenge the idea is to
have more universities running vs uh and
you can see in his website uh how many V
how many universities are running
rels
and uh if you want to be part of the Tor
Community like running relays there are
other ways to contribute with the Tor
project like uh doing trainings
translation Etc but you can also join as
a operator uh we have a mailing list
that's open and you can subscribe we
have the T Forum uh is a very easy tool
for newcomers to join and talk and ask
questions uh we have Matrix and IRC to
chat with us and we have monthly uh
online
meetups uh that are announced on the T
relays mailing list um but if you cannot
runn a relay you can also run a snowlake
proxy again uh we have uh more than
100, 4 100 more than 141,000 proxies of
of snowflake which is are very important
right now for people in Iran to access
the free and open internet and to
runlake proxy is very easy you just need
to install an add-on on your browser and
you can help people and uh yeah and uh
very curious that uh Germany is also the
top largest country contributing with
isake proxies so again thank you for
running a bunch of isake
proxies and I think that's it from me
great great Round of
Applause a great Round of
Applause for this
tour through to
networking we now have a Open
Mic you can queue up here for a few
questions so if you have a few questions
please to que up back around the back
please not running through the
camera hey thanks for talk um I really
do see that the attacks on the network
are a big problem and I find the uh
extra layer of uh social layer of trust
you want to implement interesting I can
see a few problems with that um but I
mainly wonder if it might be it if it
might undermine the spirit of tour
Spirit of anonymity if I have to
identify as a Relay operator to you
especially in a country where to operate
to operating might be illegal thank you
uh hello ah here okay yeah so this is a
great question about um transparency and
privacy uh the T Network requires user
privacy and who operates the T Network
we require transparency it doesn't mean
that we require uh phone number
identification legal names uh your
passport number we don't require that we
require like a nickname and some some
way to contact you so we are not
requiring your to disclose your legal
identity to the T project or something
like that so I think this is very
important because um we wrote recently a
document about that like the T
Rel uh expectation for T relay
operators uh which we say uh running a t
relay requires transparency so if you
cannot do that uh maybe running a relay
is not the best way to contribute with
the T Network Maybe is running a
training maybe it's localizing t maybe
it's teaching others about t so you
don't expose yourself to the T Network
because the T network is a public
network so if you are at risk maybe you
should not run a
relay thank you for these insights uh
into tour
development thank you for being here and
I think we can find you somewhere if we
have further questions find
them
oh
[Applause]
[Music]
yeah