if you essentially the a theorem
ecosystem has been growing at a very
steady pace in the last couple of years
but if you look at some of these ether
noes websites which track the number of
full nose you'll see that that one is
kind of constant or maybe even
decreasing and why is that well first up
because running a full-out sucks but and
even though we're trying to solve that
the issue is that people will always
prefer having a light client opposed to
running a full client or running in
fostering a light client or even just
using a RESTful API versus actually
connecting to infra and this is kind of
fine people are kind of more or less
aware of the implications security-wise
that okay if use a light client and the
security is not the same if using fluid
and you kind of trust them you can maybe
make a few proofs but you still trust
them and if you something like ether
scan then you know that you cannot trust
them but yeah you kind of trust them so
people can make balanced decisions
however one thing that people don't
really talk much about is what happens
for example to metadata what happens
when you actually go from running a full
node down to running a restful service
and how that actually changes the
behaviors or the the traits that you
leave behind you and that's exactly what
I would like to talk about a bit in this
talk specifically let's start with web
2.0 interfaces now my talk is relevant
for almost any depth that uses a restful
service as a background the reason I'm
picking ether scan is not to pick on
them rather because it's everybody knows
what if the scan is how ether scan works
so what is either scan just a quit in a
two-word summary basically that allows
you to check your balances your tokens
transactions events etc and apart from
that it also allows you to comment on
certain accounts if you like now this is
the surface what happens behind the
scenes well whatever you for example you
want to check your balance or ether scan
you try to load this Afghan website
which goes through cloud fair because
class there is ether scanned accelerator
ether scan returns the balance and
everything plus it also returns a
tracker code for Google Analytics
I'm better discuss forum and this might
sound like a really nice design really
elegant not too many external things
included but if we start digging a bit
into the HTTP protocol we'll see a few
surprises notably HTTP has a concept of
referrer
every time you visit a webpage from
another web page you get a Stinney extra
header saying that you came from this
website the same happens if you embed
something every time you embed an iframe
into your own little website that iframe
will get the ping that you were actually
coming from another website and why is
this bad well when you actually load for
example in this page it's a ether scan
dot io / address / 0 X whatever when you
load that Google Analytics will actually
have a ping that you this particular IP
address loaded that particularly theorum
address similarly this case also gets a
similar ping that this IP address loaded
that particularly theorum address and is
that bad well if we explore what
discussed loads the things start to get
a bit weird particularly discussed has
three types of integrations has social
logins to Facebook Google and Twitter
which means that this cuss actually
reveals the IP - if the address mapping
to Facebook Twitter and Google+ and it
also has these other weird trackers kind
of like people market a I might mining
market and all kinds of weird I can't
read this bit time here but you get the
picture so it it loads a lot of trackers
and not only that but it also loads a
lot of I think disgust has 11
integrations with YouTube Vimeo and all
kinds of other services and this is an
issue because you are essentially
associating your IP to a theorem address
mapping and you're revealing that to a
whole lot of external services and again
this is not to pick on ether scan here
and adapt is vulnerable to the same
thing it's just a bit clearer to use
with either scan and ok now we know that
there's a problem but what can we do to
actually fix it so one of the
possibilities is first of all if your
provide or any kind of that poor service
provider
first stop do not integrate legacy web
2.0 services and this might sound like a
no-brainer but if you think about it in
either scan ether scan has this
possibility to comment on account is
that genuinely a useful feature for a
block Explorer but if you look through
the comments it's pretty noisy it's
pretty spammy there are a few scams
going around on and off so it's not not
the best feature so maybe it would be
worth to cut it out the second thing is
that if you even if you don't integrate
external services or try to keep it to
the minimum you should always wonder
whether it is worthwhile to reveal
identifying information in the URL you
should always consider that anyone can
access the URL let's suppose any if
anyone can access the IP to URL mapping
do you want your customers data to be
leaked that way or not maybe for a block
Explorer maybe this is cannot be
circumvented but for other that maybe it
should be and last of last but not least
please do use HTTP referer policy
restrictions
I for example ethers can use as a policy
whereby HTTP to HTTPS forbid the
referral header from being forwarded
there are much more stricter policies
which actually forbid everything being
forwarded ok we can do that and ether
scan is actually they are trying to fix
these issues original ether scan
integrated an external ad network that
they replaced an eternal with an
internal one originally now currently
they are using Google Analytics but they
want to replace that so they are really
open to fixing issues however the issue
is that providers fixing it is not
really enough because we can get ether
scan to fix it but can we get random
that number 2000 to fix it probably not
so users need to protect themselves too
and the obvious choices here are browser
extensions that block all kinds of
checkers or if you're on a mobile device
you could for example use a brave
browser but these can only block so many
things for example if I have you to be
integrated no none of the extensions or
browsers will block YouTube which gets
us to the second point let's let's
suppose we managed to block all the
external service
even YouTube's not supposed to handle it
HTTP refers directly and everything even
then we have this fairly complex flow of
information whereby whenever we want to
access anything related to our data
either by meta mask adapt or via my
crypto or my sir wallet we still reach
out to either scan or infra or
CloudFlare in between and what this
means is that ether scan in front clouds
there still have access to the exact
same information the exact same IP
address to a theorem account mappings
now you may trust them or you may not
trust them that is up to you it's an
issue and unfortunately the only current
solution that you can do is if use an
anonymizer service kind of like tor
which is willing to hide your IP address
behind their mixing Network but kind of
that's your best chance currently so
bottom line is using restful services is
not the best thing so and if you think
now my my conclusion would be to please
use light clients yeah that's going to
get even more messy so let's dig into
life crisis
forget trustful services all together
all kinds of depths and web stuff a live
clients supposed to be the way to access
aetherium so that you don't have to run
a full node you can just run this really
nice little thing which is essentially
kind of feels like a full node just it's
not and it has actually two significant
problems one of them is in the discovery
protocol I'm not sure how many of you
are aware of how the discovery protocol
discovery layer works in aetherium or in
peer-to-peer networks in general but in
short you have a few boot notes
hard-coded into the client when you boot
up your node it reaches out to a few
seed nodes gets a whole bunch of peers
in the network and then boom you're
connected now in reality what happens
under the hood is that these boot nodes
aren't some magical special databases
that track the entire network rather
they the network itself boot nodes
included and all the other peers
included they maintain so-called routing
table or academia DHT which is kind of a
fancy way of putting that everyone knows
little piece about the network so nobody
knows the entire network but we know
little pieces of it and if you reach out
to enough of them then eventually you
can discover and you can you can
discover enough nodes to have good
connections and and have a stable stable
connectivity test essentially the issue
here is that in order to do that so
essentially a routing table requires to
be able to tell that this this
particular machine is at this particular
IP address that's what the routing table
does the problem is what happens if my
IP address is changing what happens if I
have a laptop and not I'm not running a
theorem on my home server rather on my
laptop and I keep connecting to this
theorem network from all over the world
so if I for example go last month I was
in San Francisco last week I was in
Berlin now I'm in Prague next week I'll
be in I don't know London the month
afterwards in Shanghai and I keep
connecting to this theorem network via
light client be that mobile device be
that laptop or whatever or I can even
run a full note on my laptop and do the
same thing that's completely equivalent
what the result will be is that every
time I connect to the network I am
actually revealing to the network that
this machine which last week was in
Berlin this week is in Prague and next
month I will reveal that this machine
which last month was in Prague this
month is in Shanghai and this is an
issue because this public information so
anyone in the fear network can at any
moment in time see where certain IDs are
and not only that but if you are willing
to do this for example every day just
try to scan the network every day then
actually you can create an extremely
accurate history of where each
individual ëthere node was moving over
time and just nicely plotted on the
world map now I'm not sure most people
here will be comfortable having their
three years of history usage mapped out
on a world map but how can we solve this
again it's not an obvious solution
one of the simplest thing is that as I
said the domain vulnerability is that
machines have a fixed IP address
assigned to them and if you move the
machine around and that ID ID is
essentially the global tracker so we
kind of made a cookie tracking on top of
this discovery protocol so the obvious
solution let's get rid of the IDS so
just minute now we cannot really pin it
because it's part of the etherium
protocol but what we can do is make it
as ephemeral so that every time we
restart the machine we get a new IP and
insert a new ID and this has certain
implications one of the implication is
that obviously if I'm running a boot
node the ID cannot change so boot nodes
need have special functionality whereby
the IV remains the same what happens
however if I run a full node and I just
restarted I did the update I restarted
it normally if the IV changes that's not
such a big problem in practice last
minute we told in the network that this
IP address belongs to a certain ID and
now we're telling conflicting
information and currently the theorem
discovery protocol cannot handle that so
if you keep sending in that you restart
your machine four times and you're
standing in for completely conflicting
information into the discovery protocol
then discovery protocol will just go
haywire and you will have a very hard
time do this to connect to the network
yes eventually maybe five minutes ten
minutes everything will settle down but
it is an issue and last mother last but
not least if we actually do the same
thing with live clients then we're
breaking projects that rely on this
behavior for example one of them is VIP
node and they are essentially trying to
incentivize running full nodes by
providing light servers for payment and
then live clients can pay a bit and then
they get the light server services the
issue here is that the authentication
mechanism they use is that their payment
is associated with their node ID so take
away their node ID and we just blew up
the VIP node business model and this is
I'm not saying that this is cannot be
solved what I'm trying to say here is
that these really trivial issues and
trivial fixes can have very very heavy
vacations on certain players in the
network and often we as declined
developers don't want to ruin people's
days and people's projects anyway so
that's the discovery it is an
interesting interesting problem to solve
now if we go further deep into the light
clients then how do light clients work
last I suppose we forget about discovery
let's suppose we somehow fix discovery
well that clients essentially they
connect with full nodes full servers
which actually have all the blocks and
instead of downloading the blocks and
processing them they are just randomly
picking the block headers which are kind
of is a nice enough proof that the chain
is valid but they do not download the
state and then when we start mist or any
other deck that we really care about
then the light client will actually
fetch the balance for example if I have
three accounts in mist then every time a
new block arrives mist will actually
fetch those balances for those three
accounts I care about and again this
seems like completely logical this is
the most optimal way to reduce latency
reduce bandwidth and just make all the
traffic useful except now all of a
sudden the light server knows that I am
this IP address is interested in that
particular account oh and one more I
think I want to be the head so two more
things that I wanted to say about how
the light clients work so one of them
was that they are obviously
synchronizing header and then retrieving
data on demand only interesting data
another really interesting aspect of the
light kind that I think apart from
protocol developers most people are
unaware of is that light clients cannot
verify the state so they are verifying
the proof of work but they blindly trust
that so every time you get a new block
you just assume if the proof of work is
valid then whatever state that block is
associated with will be valid and this
works because if you have a good
connectivity to the network and you have
many people sending you blocks then it's
really hard for somebody to forge a
block because yet they could forge a
block but the internet where the rest of
the network won't accept it so after
this after a few more blocks it will
just get reeled out of your
so nobody can really keep attacking you
as long as your connectivity is valid so
what happens yeah I went a bit
previously with the head but essentially
with the light clients and on-demand
retrieval the issue is that whenever if
I have missed connected and it every
whenever I have an updated lock it keeps
requesting the same balance for the same
account over and over and over and over
again the light servers will be able to
create a statistically map out that this
particular IP address is interested in
one particular address and that's a
problem because we got back to the exact
same issue an exact same behavior that
we had with the discovery protocol only
now we don't have a map world map of
moving IDs now we have a world map of
moving etherium addresses and again
similarly for the discovery protocol
this can be done exactly the same way
publicly by everyone it's a bit more
expensive because you need to run a
light server so at least you're having
the network so please if you want to
attack it and do this and not the other
fund so how can how can we solve this
and again it's a it's a hard question to
answer because it's not it's kind of
this is how the protocol was meant to be
this is the optimization so we're trying
to somehow obfuscate the optimization
and one of them is again similarly to
how we try to hide our IP address from
ether scan or from centralized the
restful services we can try to do the
same thing and maybe run live clients of
over tor but what happens if I have an
embedded device so about two weeks ago
no sorry two years ago you've already
had raspberry pi zeros as live clients
on may not somebody even had this little
Intel and buy the chips put on may not
and they were really happy that they
could they can use the light client but
these devices aren't really compatible
with tours so tour has a huge overhead
cryptographic overhead that's one
problem the other problem is that if we
start adding this these IP mixers into
the soup and trying to just create
trying to just tunnel
light client traffic all over the place
the issue is that you will have
connectivity issues so again maybe you
will find less peers maybe the latency
will go up the bandwidth will go down
you will keep dropping peers but the
issue here is that as I said previously
live clients depend on relatively good
connectivity if you have a an
application layer that essentially kills
your connectivity then all of a sudden
you kind of raise your vulnerability
against these kinds of eclipsed attacks
so again although it seems that there
would be a simple enough solution in
practice it's not so trivial so with
that said I think this was the first
talk that I did where I kind of raised
more questions than talks and then
solutions but I still I figured that I
would like I would like to formulate a
few takeaways for for you yes so that
you don't don't leave with with the
concept that ok theorem sucks and
essentially the three things that I
would really like to highlight as the
summary of this talk is that although
people don't feel like full notes full
notes are actually the best anonymizer
in a theorem ecosystem if you are
running a full note then nobody knows
what data you're interested in
you can't poke in whatever contract you
want you can check your balance as many
times per second as you want and nobody
from the outside will know that you're
actually doing it secondly privacy on
this theorem is bad really really bad
and that but this doesn't mean that it's
an impossible task to solve so there
have been existing projects that it's
two major ones the Tor network The Onion
Routing Network I mean and I to pee and
both these networks try to solve this
exact problem of how to anonymize data
so that you don't reveal too much about
yourself now I'm not saying that we
should all of a sudden put a theorem on
top of these networks these networks
have a very very broad scope and it
might be too much but nonetheless there
have been 20 years of research going
going
to how to do this properly so let's try
to at least learn from their results and
try to fix it and last but not least
I've seen it many times in the community
and I see it many times even with myself
that as a developer it's all too easy to
just say that well the users are doing
it wrong and for example it would be
nice to say that well just you store
figure it out and that's a problem
because most users don't know what
tories and most users will probably
never in their lives you store even
though that would be the obvious
solution and it's kind of up us up to us
to as the app and platform developers to
figure it out and to fix it and we don't
really want to fix it to protect the
users from not only from external
attacks I think it's really important to
also highlight that we want to protect
users from ourselves too because I just
give you a really nice example
I don't think Facebook was created to
gather user data it wasn't created to to
abuse elections that one just kind of
happened when there was too much so with
that I conclude my talk so thank you
very much
and I guess we have a few possible
questions a few minutes for questions if
I may hasn't doesn't look like we have
any hey could you talk more about
helpful notes are the most powerful and
atomizers and network with that takeaway
so essentially all these metadata leaks
as are possible because you are doing
something in your optimizing your
traffic in the network the only way to
optimize your traffic is to request only
data that interests you so every time
you are only requesting data that
interests you it means that the network
itself knows that that particular data
for some reason is interesting for that
particular IP address and this thing you
can completely hide the phone out
because the FEU node essentially gets
everything yes so that's an again
another interesting question that while
we are just reading the chain this
completely solves it a fool node but
when we are trying to transact with the
chain then then if for example somebody
manages if I'm let's say I run a
thousand full nodes and I start
monitoring where certain transactions
are coming from then that can be used to
eventually statistically hone in on a
certain IP address that this IP address
is usually originating some ID some
transaction and here here my solution as
I think for example ipfs is also looking
into exactly the same problem and their
solution or let's suppose their their
ideas are all all revolve around the I
to P protocol because it's essentially a
message based protocol that does tries
to somehow makes the transaction a bit
in the network before popping it out
somewhere and as far as I know Manero
does the same thing for the same reasons
so that's a that's possibly that's again
something that many people before us did
and people are doing concurrently with
us so it's not an unsolvable research
problem it's just an engineering problem
that we have to pay attention to
thanks for your thought it was really
good I think probably most people in
this room have done all the bad things
that you mentioned throughout the talk
so is there anything you recommend aside
from running your full no to either like
go forward or perhaps anonymize things
with these services more yeah well I
guess my recommendation I can only
recommend what I already recommended
within the within the slides that if you
are running if you are accessing block
Explorers I think browser extensions are
the single most important thing if you
if you are really paranoid then tor
network is also an essential thing so
that with with the Tor network you can
completely protect yourself against Brau
typical browser-based app that's from
tracking you if you if you are actually
willing to run a light client that's a
hard problem that's up to the client
developers will you recommend us like
general rule to regularly clean out the
node key so if as long as your server is
stable the node key is fine I mean yes
so if you are on the laptop I think that
that would be the first no-brainer
solution that we have to do is we have
to keep every so for example if you run
a light client every time you run a
light client you we should reset the
node because we should use a firmer
latkes even even better I would suggest
that maybe even four full nodes we can
use it from our own node keys and just
if we restart them yeah maybe it will
have a bit harder time connecting to the
network for the first couple minutes so
I think apart from booth knows no
nothing in the network really requires
stable keys okay can we please another
round of applause for Peter thank you
very much
[Applause]
you