►
From YouTube: PEARG Interim Meeting, 2021-01-19
Description
PEARG Interim Meeting, 2021-01-19
A
Excellent,
all
right
so
with
that
we
can
move
on,
as
this
is
an
ietf
meeting,
we're
subject
to
the
notewell.
So
if
you've
not
read
it,
please
take
a
moment
to
familiarize
yourself
with
it
and
just
a
friendly
reminder.
Please
be
respectful
and
courteous
to
others
in
the
meeting,
and
hopefully
this
should
be
super
productive
and
useful
to
all
those
who
are
participating.
A
A
The
list
of
talks
is
here
as
well
as
the
spots
in
the
email
that
sarah
sent
out
with
a
link
to
the
agenda.
You
can
find
the
pdf
documents
or
pdf
representations
of
the
slides
if
you're
interested
in
follow
following
along
that
way
before
we
go
further.
Just
a
quick
note,
the
notes
for
the
meeting
are
in
the
chat,
so
the
beeping
noise
is
not
just
you.
I
have
snoring
animals
next
to
me,
so
I
apologize
in
advance.
A
It's
yeah,
it's
a
dog,
the
the
notes
have
blue
sheets
at
the
bottom
of
the
page.
So
if
you
scroll
down
and
fill
out
your
name,
that
would
be
great.
We
also
need,
as
I
was
saying
earlier,
we
need
a
minute
taker
and
hopefully
a
job
describe
as
well
and
we
can't
really
make
for
progress
until
we
have
them.
So
I'm
gonna
pause
here
for
a
moment
and
hopefully
wait
for
someone
to
volunteer.
A
Yeah
thanks
ben
and
jabber
sprite.
Perhaps
I
don't
know
sarah,
if
you
ever
open,
could
you.
A
Okay,
awesome
and
we
have
jonathan
as
well
lovely
all
right.
I
think
that's
sufficient
with
that.
I
just
also
want
to
take
a
quick
moment
to
pause.
Anyone
have
any
sort
of
adjustments
they'd
like
to
make
to
the
agenda
as
as
is
presented
here,
hopefully
not
because
the
the
they're
structured
in
such
a
way
that
the
the
order
sort
of
makes
sense
but,
of
course,
we're
hoping
to
feedback.
A
Okay,
hearing
none,
I
guess
we
can
kick
things
off
so
first
up
is
demetrius,
phillip
and
david
to
talk
about
fraud
and
abuse.
I'm
gonna
stop
sharing
my
screen
and
we'll
pass
the
ball
over
to.
I
guess
david
yeah,
okay,.
A
David,
do
you
have
the
share
option?
Yes,
okay,
I'm
going
to
mute
now
and
about
20
minutes.
So
let's
get
this
going.
D
Cool
thank
you.
Let's
go
ahead,
get
started
we're
going
to
discuss
anti
we're
going
to
begin
things
with
anti-abuse
applications
of
ips,
so
I'm
david
from
google's
ad
traffic
quality
team,
and
today
I'm
joined
by
demetrius
from
white
ops
and
philip
from
youtube's
safety
team.
D
We've
seen
this
with
efforts
such
as
third-party
cookie
blocking
efforts
such
as
chrome's
privacy,
sandbox,
are
trying
to
provide
privacy
preserving
apis
to
address
key
use
cases
of
third-party
cookies,
and
they
also
include
fraud
and
abuse
detection
such
as
the
trust
token
api,
with
third-party
cookies
being
blocked,
browsers,
also
need
to
address
cover
tracking
in
order
to
provide
privacy
for
users.
D
Ips
are
a
fairly
stable
identifier
and
form
of
cover
tracking
that
the
ecosystem
and
this
form
are
looking
to
address,
but
at
the
same
time,
ips
have
been
very
important
for
anti-abuse
detection
across
a
broad
range
of
applications
which
we're
going
to
discuss
in
this
presentation.
So
as
solutions
are
being
developed
to
provide
ip
privacy,
it's
important
to
maintain
security
and
anti-abuse
capabilities.
D
Otherwise,
we
risk
eroding
the
trust
and
safety
of
the
internet.
What
we'll
do
next
is
go
over
several
applications.
There
are
questions,
let's
hope
them
towards
the
end
of
this
presentation.
E
E
E
Stolen
credentials
are
subsequently
used
in
credential
staffing
attacks
deployed
by
massive
botnets
that
are
tasked
to
take
over
valuable
user
accounts.
These
types
of
attacks
are
costing
businesses
millions
of
dollars
a
year
and
are
detrimental
to
users,
security
and
privacy,
and
this
is
just
an
example.
E
Mitos
we've
picked
up
on
botnets
that
are
designed
to
listen
to
music
on
large
streaming
platform.
You
know
it
turns
out
that
bad
actors
are
incentivized
to
boost
the
popularity
of
a
song
in
order
to
get
a
bigger
cut
from
copyrights.
E
E
F
Hi,
I'm
phillip
from
youtube's
stress
and
safety
group,
also
working
in
anti-abuse
for
the
past
seven
eight-ish
years.
Most
of
the
things
that
we
talk
about
in
terms
of
the
use
cases
for
ep
are
about
stopping
bad
folks
from
doing
bad
stuff,
but
they're
also
a
really
important
tool
to
help
the
rightful
owner
stay
in
their
account.
F
We
may
issue
more
challenges
like
challenge
a
second
factor
or
another
email
address
that
we
have
on
file
and
the
reason
that
we
like
doing
that
selectively
is
that
we
don't
want
to
lock
people
out
of
their
accounts.
So
we
want
to
have
that
variable.
Conf,
like
that
assessment
of
confidence
for
variable
friction
when
challenging
users,
even
in
the
good
case,
to
help
to
help
good
users.
F
When
we
talk
about
stopping
bad
folks
being
able
to
look
at
the
client,
the
originating
client
of
the
request
and
being
able
to
aggregate
on
ips
as
an
entity
is
super
powerful
for
a
number
of
use
cases.
When
we
look
at
account
creation,
we
want
to
protect
the
account
ecosystem.
The
reason
when
to
protect
it
is
bad
actors
like
having
a
large
number
of
accounts.
F
They
can
pretend
that
certain
things
are
popular,
whether
that's
ideologies
or
products,
etc
that
actually
orange
these
can
be
used
for
fraud
and,
in
those
cases,
there's
no
account
at
the
point
of
account
creation
by
definition,
and
so
ips
are
one
of
the
few
signs
that
we
can
use
to
look
for
hot
spots.
A
sign
up
activity,
account
ownership
or
account
takeover
is
a
really
important
privacy
use
case.
My
my
accounts
with
my
bank
with
my
medical
provider.
All
of
that
pii
in
there
is
only
as
safe
as
that
account
is.
F
If
somebody
takes
control
of
that
account,
they
may
have
my
email
addresses,
help
records,
etc,
really
bad
privacy
breaches
and
there
again,
because
this
is
usually
a
sign-in
type
of
abuse.
We
again
rely
on
ips
to
indicate
hot
spots
of
attempted
authentication
activity
and
also
to
get
a
sense
of
what
are
the
networks
that
are
being
used
by
different
hijacking
groups.
F
This
was
recently
surfaced
in
the
news
through
a
company
called
premier
view,
ai,
that
scraped
and
aggregated
a
whole
lot
of
information
across
the
web
in
order
to
facilitate
face
identification,
and
so
you
could
take
an
arbitrary
photo
and
then
they
would
link
it
to
real
world
identities
that
they
had
scraped
from
linkedin
and
other
service
providers.
F
Clear,
vue,
ai,
isn't
the
only
offender
in
that
field.
There
are
a
number
of
other
companies
that
have
tried
to
do
similar
ones,
including
ones
that
look
for
footage
that
people
had
taken
of
political
protests
and
then
used
images
from
that
protest.
Footage
which
was
by
itself
scraped
and
recontextualized
with
records
of
people
from
you,
know
other
services
where
the
world
really
was
established.
F
Finally,
for
low
latency
interfaces,
so
these
could
be
ticket
sales
or
you
know,
ad
auctions,
anything
where
you
have
a
split
second
to
make
a
decision,
whether
you
trust
something
or
not:
ips,
subnets,
asns,
etc
are
really
powerful
hubs
for
reputation
of
you
know
how
much
do
we
want
to
examine
this
traffic?
How
much
we
want
to
stall
this
transaction?
D
All
right
moving
on
to
discuss
data
centers
there
we
found
them
to
be
often
used
as
an
easy
way
to
scale
abuse
and
enable
cyber
crime
through
bulletproof
hosting,
for
instance.
E
The
eve
botnet
is
a
is
another
good
example
of
how
ips
are
used
for
abuse
detection.
It
is
one
of
the
largest
botnets
we've
observed
doing
outflow
in
the
past
few
years.
It
relied,
as
you
can
see
here,
on
a
number
of
different
modules,
including
a
residential
proxy
network,
hijacked
ips
and
the
well-known
culture
malware
to
deliver
its
fraudulent
payloads.
E
At
its
peak
it
was
generating
more
than
a
million
ad
requests
every
minute,
causing
tens
of
millions
of
dollars
in
losses
botnets
are
both
extremely
profitable
from
a
financial
perspective,
but
also
found
profound
privacy
violations.
Kofter,
for
example,
that
was
used
by
eve
here,
has
historically
been
known
for
distributing
ransomware
and
payloads,
designed
to
steal
personal
information.
E
In
october
of
2018,
the
fbi
executed,
an
international
takedown
people
were
indicted,
and
the
number
of
suspects
were
extradited
from
around
the
globe.
As
we
speak,
there
are
people
behind
bars
in
brooklyn
new
york.
As
a
result
of
this
takedown
ips
were
the
main
indicators
we
used
to
detect
eve
and
collaborate
with
the
law
enforcement
and
the
rest
of
the
cross
industry
group
that
took
down
eve.
I
would
go.
You
know,
as
far
as
saying
that
bringing
such
consequences
would
have
been
impossible
if
we
didn't
have
access
to
ips
next
slide.
Please.
F
Most
of
the
abuse
that
we've
talked
about
here
has
been
cyber
crime,
where
abuse
is
taking
place
in
the
virtual
world,
but
ips
are
also
quite
important
for
real
world
law
enforcement
and
real
world
crimes.
One
thing
that's
particularly
important
in
this
context
is
child
sexual
abuse
material
where
the
crime
takes
place
in
the
physical
world,
but
then
is
amplified
and
the
evidence
of
it
is
spread
online
there.
F
There
are
strong
industry
connections
with
the
national
center
for
missing
and
exploited
children
or
nitmic,
where
a
number
of
providers,
including
youtube,
share
abusive
material
with
them,
including
any
evidence
we
have
about
how
it
got
onto
the
platform
and
with
a
full
brunt
of
law
enforcement.
Things
like
ip
and
different
things
we
know
about.
The
devices
have
led
to
convictions
of
people
who
perpetrate
these
crimes
and
also
have
assisted
the
victims
and
being
freed
from
pretty
terrible.
F
Situations,
cool
and
then
I
think
the
final
wrap
up
slider,
so
I
guess
takeaways
one
is
when
we
look
at
protecting
tcp
ip
networks.
Knowing
the
address
of
the
originating
client
is
really
fundamental
to
everything.
That's
been
built
up
over
the
past.
I
don't
know
20
30
years.
F
If
we
simply
take
that
away,
it
really
empowers
the
cyber
criminals
of
all
stripes
that
operate
here.
I'm
not
just
you
know,
trying
to
hump
this
up,
but
it's
it's
really
pivotal
to
all
of
these
anti-view
systems
that
have
been
built
up.
That
abuse
in
and
of
itself
is
detrimental
to
privacy
in
the
case
of
account
takeover,
for
example,
user
trust
and
also
the
commerce
that
allows
these
services
to
sustain
the
privacy
goals
are
critical.
We
have
to
fix
the
privacy
situation,
but
this
can't
be
an
either
or
situation.
F
A
Excellent,
so
we
have
time
for
questions
for
like
eight
minutes
or
so.
If
anyone
wants
to
ask
a
question
just
pop
yourself
in
the
queue
plus
cube,
minus
key,
typical
icf
stuff
and
ask
away
otherwise
there's
a
question
from,
I
believe
muria.
I
don't
know
if
you
can
see
the
chat.
Phillip
demetrious
david,
perhaps
perhaps
you'd
like
to
respond.
F
Yeah,
the
question
is:
isn't
this
just
the
tip
of
the
iceberg
by
only
catching
those
criminals
that
are
too
stupid
to
use
tor?
So
with
a
much
I
can't
speak
directly
to
tor.
F
I
can
speak
to
just
in
aggregate
the
the
success
that
law
enforcement
has
had
and
convicting
folks,
I'm
not
sure
to
what
extent
different
proxy
services
were
able
to
provide
information
to
assist
in
those
places,
but
whether
it's
a
mixture
of
technology,
choice
or
the
traceability
of
some
of
those
things
it
it
does
appear
to
be
useful
in
those
trials.
A
Okay,
I
believe
christian
is
next.
G
Yeah,
I
mean
the
that's
a
classic
tension,
there's
a
classic
tension
between
privacy-
and,
I
would
say,
accountability
in
general-
is
that
if
everything
you
do
is
exposed,
then
the
accountability
is
much
greater
because
you
can
be
followed
for
whatever
you
did
so
that
dilemma
is
not
new
and,
and
I've
said
that
in
all
those
discussion,
it's
very
seldom
that
we
don't
hear
the
tension
between
privacy
and
child
abuse.
G
So
I'd
like
to
give
a
request
to
this
anti-abuse
presentation
to
tease
down
the
tension
there
and
specifically
tease
down
what
is
the
part
of
anti-abuse,
that
is
about
protecting
the
user
and
what
is
the
part
of
anti-abuse
that
is
about
protecting
the
service
against
the
user,
for
example.
Among
the
examples
you
gave
you
have
some
like
account
food
I
mean
taking
over
an
account.
G
G
E
I
could
take
a
first
stop
at
this
question
very
good
question.
Thank
you.
Christian.
In
the
we
presented
an
an
example
of
the
botnet,
the
eve
operation,
and
in
that
particular
case,
the
user
is
actually
a
victim.
The
user's
device
is
infected
with
malware.
That
is
dropping
a
variety
of
different
payloads,
including
a
natural
payload.
Other
payloads
could
be
you
know
a
ransomware
or
even
directly,
stealing
personal
information,
so
I
think
it's
to.
E
G
F
This
doesn't
answer
the
question,
but
just
to
add
a
dimension
to
it.
Often,
you
also
have
multiple
parts
like
in
the
case
of
the
scraping
and
recontextualization
like.
I
would
not
want
my
linkedin
profile
script
and
recontextualized
and
used
to
re-identify
me
in
some.
You
know
political
activity,
but
I'm
not
the
person
who's
accessing
it,
and
so,
in
that
case,
the
the
user,
that's
disaffected,
there
might
be
a
fairly
passive
participant
and
the
actual
transaction
involves
an
abusive
actor.
A
Okay,
in
the
interest
of
time,
I
think
we
should
move
on
to
the
next
person
in
the
queue
I
believe
is
tony.
H
Hi
yeah
tommy,
not
the
edm
program,
only
so
yeah.
Thank
you
for
sharing
this.
It's
definitely
good
to
hear
this
perspective.
I
guess
what
I
want
to
ask
is
if,
if
we
take
a
stance
in
which
we
say
okay
at
some
point,
you
know
there's
going
to
be
a
future
in
which
we're
not
going
to
be
able
to
get
the
ip
address
so
easily,
there's
going
to
be
privacy,
things
that
we're
doing
for
proxy
in
a
world
like
that.
If
we
don't
think
about
just
what
do
we
get
from
ip
today?
H
E
I
could
take
it
for
a
stop
at
it
again,
so
there
are
a
few
pieces
here
right
like
the
from
my
perspective.
The
most
important
one
is
to
get
signal
from
a
device
that
we
can
trust
and
what
I
mean
by
that
is
signal
that
we
can
almost
guarantee
that
it
hasn't
been
spoofed
until
it's
reached
our
sensors,
and
you
know
that's
from
a
threat.
Modeling
perspective.
E
The
biggest
challenge,
we've
historically
seen,
for
example,
a
modified
browser
that
is
designed
to
automatically
commit
a
credential
staffing
attack
is
often
looking
for
such
signals,
and
they
are
deliberately
spoofing
them
so
that
we
can't
do
detection
so
that
that,
for
me,
would
be
a
fundamental
thing
that
I
would
like
the
new
architecture
to
have.
I
Yeah,
can
you
hear
me
cool
so
my
question:
is
you
know
how
all
these
changes
if
it
does,
when
you
switch
to
ipv6,
is
there
anything
that
you
come?
You
can
comment
on
the.
F
F
I
Yeah
like,
for
example,
in
principle,
you
might
assume
you
might
identify
the
client,
you
know
from
the
slash
64
subnet,
but
you
know
in
most
cases
the
recommendation
is
that
a
user
gets
more
than
64
and
you
actually
don't
know
how
much
he
gets.
He
could
get
a
slash
56.
I
He
can
get
a
slash
48,
for
example.
In
my
case
I
have
like
about
six
slash
48
available
for
myself,
so
it's
tricky
because
in
ipv4
you
can,
for
the
most
part,
assume
that
the
user
is
behind.
You
know
slash
that
that
has
a
single
ip
address,
whereas
in
the
ipv6
case
for
the
most
part,
you
can
always
assume
that
he
has
a
slash
64.,
but
you
know
that
might
be
ineffective
because
the
user
might
have
like
more
than
that,
and
you
cannot
actually
tell
how
much
the
user
has
could
be.
Slash.
I
48
could
be
a
slash
56,
but
that
actually
depends
on
the
you
know
on
the
provider
on
the
isp,
so
the
specific
granularity
is
like
hard
to
tell
like,
for
example,
if
I
like
thinking
out
loud,
I
had
to
do
that.
I
probably
you
know,
start
you
know
with
a
slash
64,
but
then
still
have
to
aggregate
that
like
further,
because
then
my
the
user
might
have
control.
For
you
know
a
larger
address
space.
E
I
think
that,
unfortunately,
most
fraud
detection
companies
will
force
an
ipv4
connection
instead,
so
that
they
get
that
v4
ip.
I
So
so
sorry
you
mean
that
they
don't
consider
the
ipv6
addresses
they
will,
but
they
will.
E
E
Okay
same
thing
applies
to
ips
that
are
used
by
you
know
mobile
cellular
networks
behind,
like
that,
like
these
huge
nuts,
the
the
ability
to
use
this
as
a
as
a
stable
identifier,
degrades
in
several
scenarios,
but
it's
still
extremely
important
for
detecting
botnets,
because
on
a
large
scale,
you
still
get
a
lot
of
valuable
information
from
from
ips.
A
Case
of
we
do
have
to
move
on
to
the
next
question.
Could
you
would
you
mind
following
up
offline
or
perhaps
in
the
chat
or
something
yeah
yeah?
Thank
you
so
much.
It
was
a
great
question,
and
so
lastly,
we
have
matthew.
J
Hi,
do
you
hear
me
very
cool
yeah,
so
I'm
a
tour
developer
and
obviously
this
is
a
very
contentious
topic,
but
I
think
kind
of
following
up
on
tommy's
question.
You
know
this.
J
This
idea
that
ipa
addresses
are
so
fundamental
to
abuse,
tracking
and
anti-abuse
and
detection,
and
it
seems
like
you,
have
fundamentally
built
tracking
and
surveillance
of
users
as
a
mechanism
for
for
identifying
abuse,
and
I
wonder
how
like
how
do
you
build
a
signal
into
a
product
and
then
into
a
protocol
that
we're
trying
to
provide
privacy
while
still
revealing
some
information
that
that
lets
you
identify
when
a
user
is,
I
guess,
considered
legitimate
versus
abusive
or
a
botnet
and
like
what
does
that
signal?
J
Look
like
other
than
it
sounds
like
you
want,
like
remote
attacks
at
the
station
that
the
device
or
or
program
is
is
from
is
being
used
by
an
actual
person.
Is
that
correct.
E
That
would
be
one
piece
of
the
architecture
which
I
think
is
pretty
fundamental,
but
that
wouldn't
be
enough,
especially
for
all
the
different
use
cases
and
one
I
think
I
one
thing
I
would
mention
is
that
I
agree
that
it's
a
it's
a
high
entropy
signal,
but
the
intention
not
just
the
intention.
At
the
end
of
the
day,
what
we
are
tracking
is
a
botnet.
We
are
not
tracking.
Our
goal
is
never
to
track
humans.
In
fact,
we
almost
don't
we
don't
care
about
tracking
humans.
F
One
of
the
reasons
that
traffic
faces
challenges
across
the
internet
in
terms
of
blockages
is
that
inability,
right
now
to
say:
hey
this
subset
of
users,
big
troublemakers,
vast
majority
of
other
people,
totally
not
trouble
makers.
And
how
do
we?
You
know
that
without
going
for
a
re-identifiability
of
individual
users?
How
do
you
still
persist
that
kind
of
bad
reputation
where
it
is
important
for
the
rest
of
the
population
to
stay
safe.
A
All
right,
so,
in
the
interest
of
time
we
do
have
to
move
forward.
So
I
want
to
thank
the
speakers
for
the
great
talk
and
the
great
discussion
that
followed.
Please
feel
free
to
continue
chatting
in
the
chat
here
or
on
java
or
whatever,
or
take
it
to
the
list.
I
think
there's
a
lot
of
useful
potential
questions
to
follow
up
on.
So
next
up
is
damian
damie
and
I
have
passed
you
the
presenter's
token,
so
you
should
be
able
to
share
your
screen
now.
K
Okay-
and
you
can
hear
me
yep
okay,
so
the
the
previous
presentation
gave
an
overview
of
abuse
concerns,
I'm
going
to
be
doing
a
deep
dive
into
one
form
of
abuse
that
we've
seen,
which
is
ddos
and
botnets.
K
So
you
know
we
often
think
like
what's
wrong
with
a
little
abuse.
Like
you
know,
if
you're
dealing
with
an
ad
system
sure
there
will
be
some
click
fraud,
it
costs.
You
know
a
big
company,
a
few
million
dollars
a
year
or
more-
I
I
don't
know
exact
numbers,
but
like
what's
wrong
with
that.
Well,
you
know
what,
if
there
is
abuse
just
goes
completely
off
the
charts
right,
yeah
turn
it
up
to
11..
K
Now
now
you
have
this
problem
that
you're
not
just
dealing
with
abuse
that
costs
the
company
money,
but
maybe
you're,
putting
somebody
completely
out
of
business,
and
this
isn't
just
companies
right.
This
is
individuals
bloggers.
You
know
anybody.
Trying
to
you
know
push
put
information
online
is
at
risk
of
a
dos
attack
taking
them
down.
K
So
you
know
here's
a
post
from
a
security
journalist
pointing
out
that
you
know
some
teenager
didn't
like
his
his
posts
about
botnets
and
they
took
him
off
the
internet
and
they
actually
got
his
dos
mitigation
provider
to
kick
him
off.
So
you
know
when
we
think
about
this,
like
one
of
the
challenges
we
have
to
face
is
like
who
should
be
allowed
to
enact
global
censorship?
Do
we
want
teenagers
to
be
in
that
class
of
people
or
do
we
need
to?
K
You
know,
consider
what
to
do
about
that
and
it's
not
just
small
sites.
You
know
there
are
banks
that
see
this
and
it's
important
to
consider.
Like
you
know,
banks
are
critical
infrastructure.
This
affects
national
security
right,
and
so
you
know
these
are
sort
of
very
large
issues,
and-
and
it
can
be
quite
important,
so
you
know
we
also
need
to
think
about
how
quickly
do
we
have
to
respond
to
attacks.
K
So
you
know,
if
there's
an
attack,
it's
that
outage
is
immediate.
This
isn't
something
where
the
attack
ramps
up
slowly
over
a
day,
and
you
have
time
to
think
about
it
and
respond
and
add
capacity
like
the
instant
that
attack
starts.
You
probably
have
an
outage,
and
so
one
of
the
things
that
we
focus
on
here
is
you
know
sure
you
might
be
able
to
look
at
the
traffic
and
have
some
human
analyze
it
and
figure
out.
K
You
know
some
pattern
to
the
attack
traffic
and
you
know
triage
that
and
put
some
change
that
deals
with
that.
But
humans
tend
to
be
pretty
slow.
That's
about
20
minutes
in
in
the
best
case
scenario,
where
you,
you
know,
have
an
easy
signal
that
you
can
can
look
at,
and
so
everything
needs
to
be
automated
right.
K
Sometimes
it's
just
completely
impossible
to
to
identify
a
signature
for
the
attack
and
you
just
have
to
look
at
who
is
attacking
you
and
block
that,
and
so
we
need
these
extremely
high
fidelity
signals
of
which
you
know
an
ip
is
is
one
so
I
want
to
talk
a
little
bit
about
you
know.
What
are
the
signals
that
we
look
at
to
filter
this
traffic?
K
So
you
know
we
can
look
at
the
request
they're
making
frequently
the
request
is
just
get
slash
like
they're
fetching,
the
home
page,
not
a
whole
lot
of
information
there.
We
can
look
at
the
user
agent.
I
have
seen
a
botnet
whose
user
agent
was.
I
am
botnet
that
was
a
very
clear
signal,
but
frequently
they're
just
going
to
use
a
a
common
user
agent
or
a
set
of
hundreds
of
real
user
agents.
So
that's
not
a
a
guaranteed
defense.
K
You
could
look
at
the
referrer,
maybe
if
you're
on
a
site,
you
expect
a
referrer
to
be
from
your
site.
Botnets
now
will
spoof
a
refer
coming
claimed
to
be
coming
from
google
or
you
know,
by
do
various
other
popular
sites
search
engines.
Usually
you
know
we
can
also
look
at
the
request
rate,
but
how
do
you
know
the
request
rate?
K
If
you
don't
know
user
key
or
you
know
something
else
about
the
user,
you
need
some
ability
to
look
at
two
completely
new
users
to
your
service
know
that
those
two
users
are
distinct
from
each
other,
that
they're
not
the
same
user.
Otherwise
you
wouldn't
know
whether
those
two
requests
should
be
counted
against
the
same
bucket.
If
you
had
like
a
token
bucket
scheme
for
issuing
for
limiting
the
number
of
requests,
you
know
once
you've
identified
the
attack,
then
you
have
to
figure
out
how
do
you?
K
How
are
you
going
to
block
it
in
a
way
that
they
can't
modify?
You
know
so?
I've
already
mentioned,
like
you
know
you,
if
you
just
block
on
the
user
under
user
agent
of
im.net,
they
can
change
that
to
another
valid
user
agent.
So
we
need
some
signature
that
they
can't
easily
change
some
dos
attacks.
This
is
can
be
easy,
so
you
know
udp
amplification
attacks
like
dns
amplification.
We
can
look
for
udp
traffic
with
source
port,
53
and
block
that
that's
very
straightforward.
K
Similarly,
tcp
also
has
a
form
of
amplification
where
you
send
a
syn
packet
and
the
syn
ack
packets,
the
victim,
but
if
the
victim
isn't
expecting
to
receive
synack
package,
you
can
just
drop
all
of
this.
So
some
things
we
already
have
a
way
of
filtering
without
something
that
the
attacker
can
work
around.
K
K
We
also
need
to
think
a
little
bit
about
collateral
damage.
You
know
what,
if
multiple
users
share
an
ip,
we
see
this
today
with
net
or
carrier
grade
net.
You
know
businesses
whatever
that
can
be
great
for
privacy
right.
We
can't
distinguish
all
of
those
users.
K
You
know
if,
if
the
website
does
need
to
distinguish,
they
can
use
cookies
or
something
which
is
sort
of
a
user
acceptable
way
of
of
distinguishing
them.
But
if
we
do
a
ip
based
block,
you
know,
then
we're
stuck
with
having
to
deal
with.
You
know
what
is
the?
What
do
we
do
when
there
is
collateral
damage
and
one
of
the
tricks
we
use?
There
is
captchas,
because
that
allows
us
to
distinguish
if
it
was
a
real
user
or
not.
K
K
Okay
and
I,
and
I
just
want
to
sort
of
re-emphasize
like
how
big
these
attacks
are.
There
was
a
case
where,
in
october,
2016
a
botnet
took
down
a
dns
provider
with
a
small
syn
flood
that
led
to
a
massive
outage
of
a
lot
of
services
and
just
to
give
a
sense
of
how
important
this
was
like.
There
was
a
congressional
hearing
on
this
right,
so
this
isn't
like
a
small
thing
or
you
know,
minor
disruption
to
the
internet.
Like
people
take
this
quite
seriously.
K
This
isn't
just
the
us
liberia,
the
same
botnet
took
down
like
basically
an
entire
country
yeah
and
then
we're
also
seeing
like
you
know,
pandemics.
A
great
thing
right
now,
like
people,
are
attacking
that
as
well.
It's
anything
to
get
attention
or
to
cause
problems
so
yeah.
K
I
just
wanted
to
sort
of
reveal
how
significant
these
things
are
now,
in
that
case
of
the
mirai
botnet
that
took
down
dying
in
2016,
we
were
able
to
identify
which
botnet
that
was
and
bring
those
people
to
justice,
and
the
way
we
were
able
to
do
that
is
the
same.
Botnet
had
previously
attacked
krebs
on
security
that
journalists
had
mentioned
earlier
and
when
he
was
kicked
off
of
his
other
dos
mitigation
provider.
K
He
came
over
to
google
and
he
was
attacked
at
google
as
well,
and
we
were
able
to
record
all
of
the
ips
participating
in
that
attack
and
with
krebs
permission,
because
it's
his
site
his
data.
We
were
able
to
trust
his
ips
with
the
fbi
and
they
were
able
to
use
that
to
identify
the
people
who
you
know
the
command
of
control
for
the
botnet
trace
that
back
to
who
had
created
the
botnet
and
bring
those
those
kids
to
justice.
So
you
know
that's
an
example
of
how
ips
are
used
a
very
explicit
example.
K
K
We
had
a
case
where
we
identified
malware
that
was
compromising
people's
machines
and
sending
them
through
a
proxy
and
by
looking
at
all
the
traffic
that
came
through
that
proxy,
we
could
put
a
notification
at
the
top
of
the
search
results,
page
informing
users
that
they
were
compromised
with
this
specific
malware.
So
they
could
be
aware.
K
So
you
know
I'll
conclude
with
like
there's
a
social
good
aspect
to
this
you
know.
Yes,
everyone
believes
privacy
is
important,
but
we
need
to
think
about
what
the
trade-offs
are.
You
know,
so
we
have
to
think
about
censorship,
threats
to
critical
infrastructure
or
the
internet
itself
being
able
to
take
down
botnets.
That
could
be
a
threat
to
pretty
much
any
site
on
the
internet
and
and
also
being
able
to
notify
people
that
their
machines
are
compromised.
I
think
frequently
in
the
emphasis
on
privacy.
K
We
forget
that
if
you
don't
have
a
machine
that
is
secure,
then
you
don't
have
privacy,
you
know.
So
if
we
can't
inform
somebody
that
their
machine
has
been
compromised
because
that
would
violate
their
privacy,
like
their
machine
has
been
compromised,
they
don't
have
privacy
to
start
with
and
and
we
need
to
start
at
the
fundamentals
there.
A
All
right,
if
there
are
none,
I
think
we
can
move
on
thanks
again
for
the
presentation
certainly
good
to
hear
about
this
problem
from
all
different
perspectives.
So
next
up
in
the
queue
is
fernando
who's
going
to
talk
about
privacy.
Implications
like
addresses
on
the
client
side,
so
find
you
and
then
I
will
toss
you.
The.
A
A
I
I
So
my
name
is
fernando
gondt
and
I
will
be
presenting
an
overview
of
the
privacy
implications
of
ipv6
addresses
ip
addresses.
I
will
mostly
focus
on
ipv6,
but
then
at
the
end
of
the
presentation,
I
will
provide
a
brief
overview
for
how
this
applies
to
ipv4,
so
before
getting
into
the
specifics.
I'd
like
to
provide
like
a
very
brief
overview
of
how
ipv6
addresses
are
configured,
because
you
know
all
of
the
analysis
that
follows
you
know
essentially
relies
on
on
that
background.
I
Essentially,
in
the
case
of
ipv6,
we
have
128
long
addresses.
Normally,
we
use
those
120
long
addresses
as
64
subnets
with
64-bit
interface
ids,
and
when
it
comes
to
how
addresses
can
be
configured.
There
are
a
variety
of
mechanisms
for
that.
I
We
have
manual
configuration
which
is
obvious,
and
then
we
have
two
different
mechanisms
for
automatic
configuration,
slack,
which
is
mandatory
and
essentially
relies
on
the
host
auto
configuring
its
own
address,
whereas
we
also
have
the
hcp
version
6,
which
is
optional
and
similarly
to
the
ipv4
case,
relies
on
a
server
to
actually
lease
addresses
to
two
costs.
I
Now
the
specific
mechanism
automatic
mechanism
for
configuring
addresses
is
specified
or
determined
by
some
bits
in
participants
which
are
sent
by
local
routers.
Essentially,
evra
includes
a
prefix
information
option
with
a
a
bit
set.
That
means
that
you
will
employ
slack
for
configuring
addresses
for
that
prefix.
I
I
But
in
most
cases
what
you
do
is
employing
both
slack
and
dhcp
version
6.,
and
this
means
that
you
might,
you
might
end
up
configuring
addresses
for
the
same
prefix
with
two
different
mechanisms,
so
you
might
end
up
having
multiple
addresses
for
the
same
prefixes
configure
some,
but
via
slack
and
others
via
dhcp
version
six.
I
Now.
The
next
question
is:
how
do
we
generate
the
interface?
Ids,
obviously,
is
the
the
interface
id
is
the
like
the
host
id
in
ipv4.
If
you
wish,
like
the
remaining
part
other
than
the
prefix
in
the
case
of
slack,
we
essentially
have
like
three
different
mechanisms.
We
have
the
legacy
mechanism
that
is
specified
in
rfc
4291,
which
essentially
calls
for
embedding
the
mac
address
in
the
interface
id.
This
is
legacy
it
has
been
recommended
against,
but
some
still
use
it.
So
that's
why
I'm
still
referring
to
it.
I
Then
there
is
the
mechanism
specified
in
rfc
7217,
which,
let's
say
in
a
simplified
way.
It
calls
for
computing
the
interface
id
by
hashing,
the
network
prefix
the
subnet
prefix,
with
a
secret
with
a
secret
key,
and
then
there's
also
the
temporary
addresses
specified
in
in
4941
and
being
revised
right
now,
the
the
a
common
revision
it
should
be
out,
like
you
know,
anytime
soon,
which
essentially
calls
for
randomizing
the
interface
identifiers
and
regenerating
them
over
time.
I
I
What
happens
for
most
of
typically
for
most
implementations
is
that
the
servers
employ
like
a
small
address,
pool
from
the
whole
slash
64
and
generate
the
addresses,
as
a
linear
sequence,
like
most
trivial
case
would
be
to,
for
example,
start
with
column,
column,
one
and
then
the
next
host
that
asks
for
an
address
gets
the
column,
column,
two
etc,
etc.
I
So
that's
as
much
for
the
background.
So
now,
let's
jump
into
the
privacy
implications
of
ipv6
addresses
the
implications
for
the
most
part
have
to
do
with.
You
know
how
you
generate
the
interface
identifiers
and
there
are
a
number
of
properties
that
are
related
to
the
interface
identifiers,
that
you
know
have
consequences
when
it
comes
to
privacy.
I
First,
one
is
the
stability
of
the
interface
identifiers
and
the
you
know.
The
basic
idea
is
that
the
more
stable
the
interface
identifier
is,
you
know
the
longer
and
the
larger
the
scope
in
which
you
can
correlate
network
activity,
for
example,
one
extreme
if
you
have
interface
identifiers
that
are
constant.
That
is,
you
use
the
same
identifier,
no
matter.
I
You
know
which
network
you
attach
to
then
those
will
allow,
for
you
know
even
cost
tracking,
like
you
know,
correlating
network
activity,
even
as
you
move
from
one
network
to
another,
then
on
the
other
extreme,
if
you
are
using
randomized
interface
identifiers
or
just
let's
assume
that
you
use
one
different
address,
you
know
for
each
let's
say:
tcp
connection
that
you
establish,
then
you
know,
network
activity,
correlation
becomes
more
mitigated
or
becomes
more
difficult
to
some
extent
another.
I
You
know
characteristic
of
of
addresses
and
in
this
particular
case
we
are
kind
of
like
talking
about.
The
aggregate
is
that,
if
you
are
on
a
network
and
the
interface
identifiers
on
that
network
follows
patterns
of
different
swords,
then
that
will
normally
make
other
scans
possible.
We
will
go
through
these
into
more
detail
later
and
the
final
one
is
that
you
know
the
the
the
basic
requirement
for
addresses
are,
of
course,
that
they
are
unique.
Okay.
I
Now,
for
example,
in
the
case
that
I
mentioned
before,
where
you
generate
the
address,
or
the
interface
id
in
particular
by
embedding
a
mac
address,
you're
actually
overloading
the
semantics
of
the
address,
and
that
means
that
the
interface
id
is
not
just
a
simple
or
back
number,
but
actually,
you
know,
has
overloaded
semantics
and
it
will
normally
leak
or
disclose
more
information.
I
Now,
a
very
brief
overview
of
each
of
these
things
that
I
mentioned
before
I
mentioned
there
were
activity
correlation.
Essentially,
you
have
two
basic
forms
of
attack.
One
is
a
passive
variant
of
the
attack
and
the
other
one
is
an
active
bearing
now
in
the
passive
variant.
Essentially,
you
have
a
host
that
you
know
connects
to
one
network
network,
one
in
this
case
and
it
configures
the
others
by
embedding
the
the
my
calories.
I
Okay,
then,
if
that
node,
if
that
host
moves
to
a
different
network,
if
the
host
is
employing
a
constant
interface
identifier,
it
will
employ
the
same
interface
id
as
before
and
since
this
number
is
unique,
for
you
know
that
can
be
assumed
for
most
cases,
then
that
interface
identifier
becomes
like
a
super
cookie
and
you
can
essentially
identify
the
user
by
simply
looking
at
the
ip
address.
I
The
second
bearing
for
tracking
network
activity
is
like
an
active
attack
version.
So
let's
assume
that
we
have
an
attacker
that
is
targeting
a
specific
user
that
employs
constant
interface
identifier
in
constant
interface,
identifiers
and
the
attacker
knows
that
there
are
a
specific
subset
of
networks
where
these
victim
could
attach
to.
So,
if
I
want
to
find
you
know
where
this
target
user
is,
I
could
actually
prove
you
know
what
should
be
the
address
of
that
user
within
that
network.
I
So
if
I
know
the
subnet
prefix-
and
I
also
know,
what's
the
interface
id
that
that
user
would
employ
in
that
network,
I
can
simply
send
some
sort
of
proof
packet.
I
If
I
don't
find
it,
I
could
proceed
to
the
other
network
and
then,
finally,
to
the
last
network,
where
the
article
where
the
victim
actually
is
okay,
so
that
as
much
for
activity
correlation
what
about
other
scans
well,
ipv6
saturday
scans
were
originally
considered
and
feasible,
because
you
know
having
64
bits
for
the
subnet
means
that
there
are
so
many
addresses
there
that
you
couldn't
actually
brute
force
scan
all
of
that
address
space.
I
But
if
you
have
interface
ids
that
actually
follow
patterns,
then
you
know
the
search
space
actually
can
be
reduced
quite
a
lot.
I
will
provide
just
two
examples.
Just
consider
the
case,
for
example,
where
dhcp
version
6
server
lists
addresses
from
slash
112.
I
Now
the
others,
the
the
search
space
obviously
has
been
reduced
a
lot
and
if
you
wonder
yeah,
this
is
done
quite
a
lot
by
many
dhcp
server
implementations
and
you
could
also
have
other
cases
where,
for
example,
sites
manually
configure
or
somehow
configure
the
the
interface,
the
interface
ids
to
the
ipv4
address
of
the
same
network
interface-
that's
quite
popular,
for
example,
for
content
delivery
networks.
I
Okay,
now,
in
all
of
those
cases,
you
will
have
reduced
the
search
space
and,
if
you
wonder
yeah,
there
are
tools
that
scanning
tools
that
actually
leverage
patterns
not
only
these
two,
but
also
many
others
to
actually
be
able
to
find
to
to
perform
other
scans.
I
The
final
one
was
device
specific
attacks,
and
the
idea
is
simple:
if
you
look
at
the
legacy
scheme
for
generating
interface
identifiers,
essentially
it
calls
for
embedding
the
mac
address
in
the
interface
id.
That,
of
course,
reveals
your
mark
address,
but
not
just
that,
because
the
mac
address
also
reveals
the
bender
of
your
network
interface
car,
and
this
could
be
exploited
in
some
scenarios
for
attackers
to
be
able
to
perform
device-specific
attacks
in
which
they
can
simply
learn.
I
What's
the
manufacturer,
for
example,
of
your
network
interface
card
by
looking
at
your
ipv6
address
without
any
further
help,
so
I
have
provided
this
summary
table
for
you
know
how
all
of
these
you
know.
Aspects
applies
to
the
different
schemes
that
we
have
for
generating.
You
know,
interface
identifiers.
I
I
will
not
go
through
detail
for
each
of
these
because
of
time
constraints,
but
you
can
see
that
in
the
worst
case
scenario
you
have
the
legacy
scheme
specified
by
4291,
where,
essentially,
you
know
if
interface
ids
are
configured
with
that
scheme,
the
you
know
the
addresses
are
subject
can
be
subject
to
cost
tracking
correlation
within
the
same
subnet
address
scans
device,
specific
and
device
specific
attacks.
I
Actually,
if
you
look
at
4941
itself,
it's
not
so
much
the
case
because
it
has
some
flaws,
but
when
we
get
to
publish
the
revised
specification
anytime
soon
that
this
should
be
the
case
where
most
of
the
things
are
mitigated
still
there's
some
correlation
possible
within
the
same
subnet,
because
of
course
these
are
temporary
addresses
which
change
over
time.
But
it's
not
that
you
use
one
address
for
each
network
activity
that
you
perform.
So
there's
still
some.
You
know
level
of
activity
correlation
that
is
possible.
I
There
are
some
things,
some
some
habits
to
consider,
which
I
will
not
get
into
detail,
but
let's
just
mention
them
when
analyzing
the
things
you
need
to
consider
all
of
the
address
configuration
mechanisms
because,
for
example,
you
could
have
you
know
your
system
doing
the
right
thing
for
slack
like
doing
7217
and
temporary
addresses
for
slack,
but
then
you
attach
to
a
network
that
has
a
dhcp
server
that
releases
predictable
addresses.
That
was
my
case
at
home,
for
example.
So
you
have
to
keep
this
in
mind.
I
You
also
need
to
consider
the
implications
of
all
of
the
different
addresses
that
you
use,
because,
for
example,
your
host
might
employ
both
stable
and
temporary
addresses,
and
sometimes
with
this
happen,
people
just
consider.
You
know
the
the
how
all
these
things
affect
you
from
the
point
of
view
of
the
temporary
address.
But
you
know
normally
you
get
the
union
of
the
vulnerabilities
of
both
of
the
addresses.
That
of
all
of
the
address
types
that
you
employ.
I
Other
things
to
consider
is
how
all
this
affects
networks,
where
you
have
stable
prefixes
and
you
have
a
low
host
density
and
why
well
because,
for
example,
if
you
have
a
network-
and
you
have
a
let's
say,
a
single
host
and
the
network
employs
a
stable
prefix.
Well,
even
if
the
host
actually
changes
its
address
well,
it
will
still
be.
You
know
it
would
still
be
possible
to
correlate
and
never
activity
based
on
the
stable
prefix.
I
So
that's
something
to
consider,
and
the
final
thing
to
consider
at
least
as
far
as
this
list
goes
is
that
you
should
also
consider
you
know
how
mac
address
randomization
affects
all
these
or
to
the
other
way
around.
I
How
the
way
in
which
we
configure
addresses
affects
my
category
randomization,
because,
for
example,
you
could
be
changing
your
ipv6
addresses,
but
you
might
not
be
randomizing
your
mac
address
and
now,
if
defaults,
essentially
trying
to
do
activity
correlation,
are
you
know
present
on
the
hotspot,
then
you
know
what
you
do
at
the
ip
layer
might
not
affect
what
they
are
doing.
C
Finally,
fernando
just
a
quick
time
check
we're
running
up
against
time
now
for
the
talk,
I
don't
know
if
you
want
to
just
run
through
these
two
thoughts
quickly
and
then
I
can
take
one
or
two
questions.
I
Yeah,
essentially
for
ipv4,
we
have
two
scenarios
where,
in
the
case
where
you
have
nuts
in
the
case
where
you're
not-
and
this
is
a
way-
this
is
the
how
you
are
affected
in
those
cases
you
know
in
the
case
in
which
you're
not
normally
correlation
is
more
difficult
and
so
on,
whereas
in
the
case
where
you
are
not
not,
there
are
some
things
that
you
are
kind
of
like
protected
against,
but
other
things
become
possible,
such
as
you
know,
correlation
within
the
subnet
and
other
scans.
So
that's
mostly
it.
A
Excellent,
so
as
before,
we
do
a
time
for
one
or
two
very
brief
questions.
There
is
one
in
the
chat
for
you,
fernando.
If
you
want
to
check
it
out
from
caleb.
I
Okay
regarding
this
table
prefix,
there
has
been
a
survey
that
says
that
about
35
percent
of
the
surveyed
users
are
employing
stable
prefixes.
So
that's
the
data
that
the
only
data
that
I
could
provide.
That's
a
survey,
so
I
I
wouldn't
be
able
to
tell
you
know
how
representative
that
is
and
in
though,
in
the
cases
where
they
are
not
employing
a
stable
prefixes,
it
varies
the
extent
to
which
the
prefixes
are
not
stable.
For
example,
it's
quite
common
for
isps
to
rotate
the
prefix
once
a
day.
I
So,
whether
that's
stable
enough
or
not,
it's
you
know,
it's
depends
on
the
point
of
view.
A
I
A
Next
up
we
have
christian
christian.
I
passed
you
the
token
okay,
in
your
sharing.
A
And
while
you
bring
that
up,
stephen
asks
a
question
for
me,
but
I'm
going
to
relay
it
for
the
group.
We
are
running
a
bit
over
schedule
right
now,
so
in
the
interest
of
keeping
the
discussion
going,
we're
not
going
to
you
know,
cut
anyone
off
earlier.
We
might
just
have
to
overflow
into
the
next
meeting.
So
anyways
carried
away
christian.
A
C
C
Yeah
george,
would
you
be
ready
to
speak
if
we
put
you
in
here
and
we
come
back
to
christian.
M
Oh
yes,
I
think
I
can
do
that.
A
Okay,
christian
we're
gonna
pass
the
ball
over
to
him.
A
C
M
A
It
is
loading
I'll,
let
you
know
when
we
can
see
something.
A
Would
you
like
to
do
well,
your
screen
sharing
doesn't
appear
to
be
working
and
since
christian
figured
it
out,
I'm
just
going
to
quickly
toss
it
back
to
him.
Sorry,
george,
sorry
everywhere.
G
A
Your
yes.
G
That
was
one
slide
too
many,
I'm
sorry!
Yes,
so
basically,
the
the
design
is
that
you'll
send
a
lot
of
activity
for
a
pooling
server
and
then
the
activity
will
be
coming
out
and
an
attacker
that
observes
what's
coming
in
the
server
and
comes
out.
The
server
cannot
make
heads
or
tail
of
it,
because
there
is
too
much
traffic
coming
in
to
be
able
to
easily
correlate
what
comes
into
what
goes
out,
and
this
design
is
found
in
many
many
privacy
tools.
G
Obviously,
obviously
use
dns
relies
on
that
and
cryptid
sni
relies
on.
That
too
I
mean
basically,
the
idea
is:
you
include
the
the
sni
and
then
you
send
that
to
a
fronting
server
that
supposedly
choose
between
very
many
plausible
server
on
the
other
side,
and
so
the
attacker
doesn't
know
which
one
you
used,
and
so
it's
basically
all
these
anonymity
pool
design
and
my
problem
with
that
in
the
next
slide.
G
Then
it
becomes
really
easy
for
an
attacker
to
correlate
when
comes
in
and
what
comes
out,
and
so
my
my
wonder,
was
hey:
do
we
have
a
problem
in
practice?
Do
we
have
a
problem
that
affect
a
number
of
our
privacy
designs
and
I
believe
we
do
and
the
example
of
that
is
the
privacy
provided
by
encrypted
sni
or
h?
If
you
prefer
next
slide.
G
Basically,
what
they
did
is
that
they
took
the
top
one
million
domain.
They
were
using
both
at
least
from
alexa
and
the
magic
million
and
etc,
and
they
looked
at
how
those
address
gets
reused.
Among
those
million
top
side
and
the
high
level
summary
is
they
don't
get
you
we
use
very
much.
I
mean
if
you
look
at
their
the
community
frequency
distribution
curve
that
are
on
the
right
of
my
of
my
slide
there
you
see
that
most
ip
address
are
used
by
exactly
one
server.
G
I
mean
by
just
looking
at
the
ip
address.
You
can
retrieve
the
information.
The
ipls
of
the
server
will
tell
you
just
as
much
information
as
the
sni
would
do,
and
even
in
if
the
case,
if
there
are
a
few
servers,
you
see
that
in
the
current
in
the
cfd
curve,
95
percent
or
so
of
the
more
than
90
of
the
of
the
server
share
the
address
with
fewer
than
10
other
ip
addresses.
G
So
let's
go
to
the
next
slide
about.
What
can
we
do
about
that
and
what
I
think
we
should
be
doing
about
that
is
adopt
as
a
general
principle
that
if
we
want
to
hide
something,
we
have
to
rely
on
choice,
not
chance,
for
example,
take
the
example
of
obvious
dns,
which
is
design
on
that
I
mean
the
idea
of
use.
Dns
is
that
you
go
through
three
layers
of
dns
server.
G
G
G
G
Now,
if
we
said
that
the
proxy
is
actively
providing
an
a
privacy
service,
you
have
a
question
about
how
are
those
proxy
going
to
be
deployed
exactly,
and
there
have
been
many
approaches.
Basically,
the
the
main
two
approach
we
see
today
are
large
tech
companies
deploying
big
proxy
or
big
sharing
service.
I
mean
an
example
of
that
would
be
google
dns,
for
example,
that
mixes
the
traffic
of
a
bunch
of
people
and
and
then
makes
it
hard
so
that
the
actual
dns
request
cannot
be
easily
identified.
G
G
Typically,
someone
will
run
a
server
in
a
university,
for
example,
and
at
some
point
the
university
management
will
tell
them
hey
that
server
that
you
are
here
is
costing
you
a
lot
of
money
who
is
using
it
and
they
dig
a
little
and
they
say
that
some
pretty
on
salary
people
are
using
it
to
do
porn
or
worse,
and
it
says
hey.
Why
are
we
paying
for
that?
G
And
then
they
close
it
and
you
can
have
cascading
failures
of
volunteer
service
by
that
kind
of
mechanism,
because
once
one
close
the
load
on
the
other
increases,
etcetera,
etcetera,
it
can
be
spiraling
and
yet
another
alternative
is
to
have
specialized
services.
I
mean
that
as
india,
the
picture
provides
for
your
hiding
services
and
you
buy
the
superior
hiding
service
from
your
service
that
somehow
charge
our
users.
G
So
we
have
this
dilemma
there
that
open
access
invite
forward.
But
if
the
solution
to
open
access
is
to
have
a
service
you
pay
for
then
that
service
has
to
identify
that
you
are
a
valid
customers
in
order
to
give
you
access
and
does
this
privacy
service
force
you
to
identify
yourself,
which
is
kind
of
a
contradiction.
G
That
means
that,
basically,
if
you
go
to
a
privacy
server
instead
of
sending
your
identity,
you
pass
some
kind
of
token.
That
is
blinded,
and
that
says
yes,
I
am
a
good
user.
Is
the
proof
and
those
tokens
can
then
be
treated
pretty
much
like
micro
payments
to
protect
the
privacy
service
and
make
sure
it
is
not
abused.
G
G
A
Much
all
right,
we
probably
have
time
for
a
quick
question.
Anyone
in
the
queue
it's
like
damien
is
in
the
queue.
If
I'm
reading
this
correctly
another
question
you
can
read
this
question
a
lot
answer:
it
yeah.
G
G
I
could
say
that
the
generic
solution
there
is
to
shuffle
that's
also
why
I
would
like
to
I
mean
I'm
worried
about
having
to
authenticate
to
the
proxy,
but
even
without
authenticating.
It's
indeed
the
case
that
the
proxy
can
track
ipa
buses.
G
So
it's
probably
the
case.
I
mean
in
tor
it's
it's
well
known
that
you
try
to
have
at
least
three
layers
of
proxies
in
order
to
minimize
these
kind
of
cases,
but
we
have
to
look
at
the
architecture
of
proxying
to
provide
guarantees.
If
we
just
hope
for
natural
anonymity
pools,
it
won't
work
if
we
hope
if
we
try
to
reuse
other
services
like
vpns,
it
will
also
not
work
because
of
these
tracking
effects.
A
Yeah
great,
thank
you
just
a
quick
one
to
know
for
people
who
are
perhaps
not
familiar
with
the
work
on
going.
The
itf
on
privacy
pass
that
has
flavors
of
the
things
you're
discussing
here,
especially
around
sean's
work
earlier
on
blinded
signatures
and
digicash
and
stuff.
So
that
might
have
that
might
be
relevant
to
the
discussion
that
perigee
should
hopefully
embark
upon.
A
A
M
For
my
internet
going
down
okay,
so
let's
let
me
try
to
share
this
thing.
Hopefully
it's
gonna
work
this
time,
let's
see
if
it
doesn't
work,
we'll
have
to.
M
M
M
All
right,
let's
go
all
right,
so
hello
people,
I'm
george,
I
work
as
an
engineer
on
tour
on
this
talk.
I'm
gonna
give
you
like
a
basic
rundown
of
what
door
is
doing
at
this
stage.
The
next
steps,
and
also
I'm
gonna,
touch
a
bit
on
the
denial
of
service
prevention
and
a
bit
of
discussion
and
possible
countermeasures
which
seems
relevant
to
the
things
being
said
before
so
on
the
next
slide.
M
So
I'm
not
gonna
go
on
the
technicals
of
how
tor
works.
I'm
gonna
assume
that
people
kind
of
know
this,
but
thor
is
capable
of
protecting
the
ip
others
of
alice
the
client
on
the
left
side,
but
also
of
bob
on
the
right
side.
So
it's
able
to
to
both
protect
the
anonymity
of
of
users
like
me,
but
also
of
services
like
websites
or
whatever,
and
it
does
this
through
the
use
of
an
anonymity
network
which
is
the
tor
network
on
the
next
slide.
M
So
we
can
see
that
tor
has,
depending
on
how
you
count,
because
it's
not
easy
to
measure
the
clients
of
an
anonymous
network.
We
have
about
2
million
users,
but
other
researchers
have
have
counted
up
to
8
million
users,
so
we
have
many
millions
of
users
on
the
daily
and
on
the
next
slide
you
can
see
the
network
size,
which
is
the
number
of
relays.
M
M
So,
on
the
next
slide
right
now,
we're
constantly
working
on
improving
tour
towards
all
directions.
M
So,
for
example,
we're
currently
doing
lots
of
work
on
performance
improvements,
so
we
are
aiming
to
improve
our
congestion
control
because
our
network
does
have
a
lot
of
capacity,
but
because
our
congestion
control
is
sucky,
it
doesn't
we.
We
cannot
use
all
that
capacity
effectively
we're
looking
at
at
various
load,
balancing
improvements
and
other
stuff,
like
that.
Also
we're
constantly
working
on
improving
security
in
various
ways,
both
on
the
protocol
side,
but
also
like
on
the
you
know,
on
the
binary
side.
M
So,
for
example,
we
are
we're
investigating
how
to
move
to
rust
instead
of
c,
because,
right
now,
the
core
demon
of
thor
is
a
huge
sea
demon.
We're
also
constantly
working
on
ux
improvements
on
our
browser,
because
that's
the
product
where
our
users
interact
with
the
network.
It's
it's
basically
a
browser,
also
better
api
for
mobile
integration
and
better
censorship
circumvention,
because
there
is
many
many
users
who
use
store
to
circumvent
censorship,
especially
in
certain
countries.
M
So
this
is
like
the
stuff
that
we're
working
on,
but
I
think
more
to
the
interest
of
this
group.
Please
next
slide,
I'm
gonna
talk
about
denial
of
service
attacks,
so
we
denial
of
service
attacks,
as
I
said
before,
in
the
previous
conversations
are,
are
notoriously
hard
to
defend
against
and
especially
on
on
the
decentralized
network
with
anonymity,
because
we
don't
have
ip
addresses,
we
don't
have
reputations.
M
Sometimes
we
don't
even
know
if
an
attack
is
going
on.
So,
for
example,
in
the
beginning
of
january,
our
network
was
being
attacked
and
it
was
actually
hard
to
distinguish
whether
it's
a
malicious
attack
or
someone
coded
a
client
that
was
doing
very
stupid
things.
So
next
slide,
please
so.
M
Denial
of
service
attacks
on
tor
are
in
various
places.
So,
for
example,
they
can
be
attacking
the
network
by
shutting
down
the
relays
or
shutting
down
the
directory
authorities
or
causing
chaos
over
there,
but
they
could
also
be
on
the
right
side
so
on
the
service
side.
So
when
I
told
you
that
we
can
have
anonymity
on
the
server
side,
that's
onion
services
and
there
are
also
attacks
that
can
happen
there
and
next
slide.
Please.
M
So
so,
right
now,
onion
services
are
being
attacked
by
denial
of
service
adversaries,
and
these
adversaries
are
currently
exploiting
the
asymmetries
of
the
of
the
tor
protocol
when
it
comes
to
onion
services.
So
the
basic
idea
here
is
that
you
know
a
client
sends
a
message
to
the
onion
service
and
to
do
that,
it
uses
work
x,
but
the
service
to
respond
effectively.
It
needs
to
consume
work
10x.
M
So
this
asymmetry
is
what
makes
onion
services
particularly
juicy
for
dos
attacks,
and
it's
basically
what
the
attackers
do
so
so
far,
we've
been
we've
been
deploying
various
defenses,
but
they
are
all
kind
of
trying
to
reduce
this
asymmetry.
You
know
these
multipliers
kind
of
reduce
them
chip
them
down
a
bit.
So,
for
example,
we
have
onion
balance,
which
is
like
a
tool
to
do
some
geographical
load
balance
of
of
onion
services.
M
So
you
know
you
split
your
onion
service
into
10
nodes
instead
of
one
node,
but
you
know
this
is
this
is
a
defense,
but
it
just
does
a
it.
Just
removes
a
a
multiply
of
on
the
number
of
nodes.
It
doesn't
really
do
a
big
order,
magnitude
change
and
when
we're
talking
about
motivated
adversaries
and
when
we're
talking
about
a
protocol
with
a
big
asymmetry
many
times
this
geographical
load
balancing,
does
not
really
address
the
core
of
the
problem.
M
M
So
now
I'm
gonna
talk
to
you
about
two
defenses
that
are
more
in
depth.
There
is
actually
another
slide
here,
but
because
we
did
this
thing,
I
don't
have
it,
but
anyway,
let's
keep
this
slide
still.
So
the
the
first
defense
I
want
to
go
into
is
a
defense
based
on
proof-of-work
schemes
and,
in
my
opinion
it
it
is
extremely
effective
against
low
to
medium
strength,
adversaries,
but
not
effective
against
larger
adversaries.
M
The
idea
is
that,
before
clients
contact
the
online
service,
they
have
to
solve
their
profitable
puzzle
and
we
went
into
designing
such
a
defense
and
finding
such
a
proof-of-work
system.
And
if
you,
if
you
look
closely,
you
can
find
proof-of-work
systems
that
fit
are
designed
restrictions.
So
they
are
quick
to
verify,
because
you
don't
want
the
verification
of
the
proof
of
work
to
become
a
threat.
They
have
a
proof
size
that
is
small
and
also
they
are.
M
They
have
gpu
resistance,
so
you
know
if
an
attacker,
so
a
botnet,
for
example,
tries
to
to
to
compete
with
regular
clients.
The
botnet
will
have
to
spend
much
more
cpu
work
to
to
get
requests
to
to
go
through,
and
the
system
we
designed
is
has
like
a
in
quotes
a
proof-of-stake
mechanism,
so
it
doesn't
prioritize
all
of
the
requests
the
same
and
instead
depending
on
the
strength
of
the
proof
of
work
token,
it
prioritizes
them
accordingly.
M
M
So
this
actually
has
been
suggested
before
in
the
ssl
working
group
by
alex
pierkov
and
another
group
to
do
client
puzzles
for
tls,
because
tls
suffers
from
a
similar
issue
where
client,
hello
is
cheap,
but
server,
hello
and
service
certificate
and
all
that
stuff
is
kind
the
heavier.
M
So
this
has
been
suggested
before
and
it's
something
that
we're
looking
to
experiment
with
next
slide.
M
Please
thank
you,
but
let
me
go
into
a
defense
that
I
think
is
more
relevant
to
the
discussion
here
both
because
you
know
I
don't
think
big
services
can
ask
their
users
to
wait,
10
minutes
or
even
2
seconds
more
because
speed
is
paramount.
M
So
ok,
so
let's
talk
about
anonymous
credentials,
christian
from
the
talk
before
mentioned
them,
so
I'm
gonna
continue
building
on
the
on
the
topic,
because
I
think
it
has
lots
of
lots
of
things
to
do
with
the
conversation
here.
So
the
idea
is
that
an
anonymous,
credential
or
a
token
so
to
say,
is,
like
you
know,
it's
like
a
train
ticket.
So
it's
a
it's
a
it's
a
it's
a
little
thing,
a
token
that
you
have
and
it's
unlinkable
to
your
identity.
M
So
if
you
show
it
multiple
times
the
person
who
validates
it
cannot
link
those
users
between
them.
These
redeem
redeems,
they're,
not
linkable,
and
they
have
various
properties,
so
you
can
think
of
it
as
a
train
ticket
which
you
can
get
stuff
with,
but
it
doesn't
write
your
name
on
and
if
you
throw
it
on
the
street
and
someone
finds
it,
they
cannot
link
it
to
your
actual
name.
So
we.
C
George
sorry,
to
jump
in
again
we're
running
short
on
time.
We've
got
a
couple
more
minutes
for
your
presentation.
If
I
could
ask
you
tomorrow,.
M
Sorry,
thank
you
no
problem,
so
this
has
been
used
before
in
technologies
like
privacy
pass
and
signal,
and
we
think
that
it's
going
to
be
quite
useful
for
the
denial
of
service
defenses,
because
you
know
you
can
better
control
the
clients
that
go
into
the
onion
service
and
which
note
and
also,
I
think
it
has
lots
to
do
with
the
reputation
of
exit
nodes,
because
we
can
start
better
controlling
the
clients
who
reach
the
exit,
nodes
and
kind
of
have
a
better
reputation
based
system,
but
without
anonymity
leakage.
M
So
next
slide
please.
So
we,
the
anonymous
credential
scene,
is
just
getting
started
and
there
is
tons
of
schemes
out
there
all
with
different
properties.
So
you
can
have
revocation
you
can
have
delegation.
There
is
lots
of
properties
and
lots
of
crypto
to
handle,
and
it's
something
that
people
are
working
on
these
days
and
it's
something
that
we
in
tour
are
also
monitoring
closely
to
see
how
it
fits
us
and
what
we
can
do
with
it
next
slide.
Please.
M
All
right,
so
these
are
a
few
ways
we
hope
to
get
across
and
how
we,
we
hope
to
tackle
denial
of
service
attacks
in
the
future,
and
we
are
looking
forward
to
more
standardization
work,
both
on
proof
of
work
systems,
but
also
on
the
design
and
implementation
of
anonymous
credential
schemes
that
have
properties
and
performances
that
can
be
used
in
everyday
life.
So
thanks
a
lot-
and
this
was
my
presentation.
A
Questions
virgin
is
one
for
you
specifically
sort
of
a
meta
question.
Would
you
mind
linking
to
the
spec
proposals
which
describe
the
proof
of
work
and
the
anonymous
credentials
base
solutions
here
in
the
chat
for
posterity,
so
others
can
check
them
out
if
they're
interested.
N
A
Right,
so
if
there
are
no
other
questions,
I
think
we
can
move
on
to
the
next
presentation,
which
is
justin
just
as
before.
I'm
going
to
try
and
give
you
the
token.
A
P
A
A
P
All
right
thanks
all
right,
so
I'm
justin
yuberti
and
I've
worked
on
webrtc,
where
we've
had
to
try
to
come
up
with
techniques
to
allow
clients
to
connect
with
each
other
peer
to
peer
while
simultaneously,
not
providing.
You
know
additional
information
on
ip
addresses
that
would,
you
know,
harm
privacy
next
slide.
P
P
P
Next,
next,
okay,
so
you
know
what
happens
you
know,
each
browser
on
the
request
of
the
application
will
open
up
a
udp
socket
and
get
that
ipport
tuple
of
their
local
network
interface.
The
browser
then
provides
this
information
to
the
app
you
know
saying:
hey.
You
have
an
address
that
you
can
use
for
the
other
side
to
reach
you,
then
the
app
will
use
its
own
sort
of
mechanism.
It
can
be
over
xhr.
P
So
that
gives
the
application
a
lot
of
flexibility
into
how
it
does
that,
but
it
also
means
the
application
has.
You
know
now
can
see
the
actual
ip
address,
and
this
causes
his
own.
You
know
issues
which
I'll
get
to
in
a
minute
next
slide,
so
you
know
how
this
works
in
practice.
Just
sort
of
you
know
illustrating
it.
You
know,
client,
a
on
the
left
in
blue,
you
know
gets
its
own
local
network
interface.
P
And
then
client
b
will
do
the
same:
it'll
get
its
own
network
interface
address
and
an
alkyl
port,
and
that's
the
other
side.
So
now
both
sides
can
try
to
make
a
connection
with
each
other
next
slide.
P
Okay,
so
you
know
we
can
establish
these
peer-to-peer
connections,
and
this
is
great,
especially
for
things
inside
like
a
lan.
It
can
allow
for
very
efficient.
You
know
picture
peer
distribution
of
media
or
other
certain
large
files
or
other
communications
that
require
latency,
but
the
app
has
access
to
ip
address
information
that
it
wouldn't
otherwise
have
had.
You
know.
P
Typically,
the
app
can
see
you
know
in
the
web
server
the
address
from
the
client
from
which
it
connected,
which
will
typically
be
an
added
address,
but
here
it'll
be
able
to
actually
actually
access
the
ip
interface
of
the
machine,
and
you
know
that
sort
of
you
know
interface.
You
know
the
ip
information
plus
the
you
know.
The
publicly
visible
ip
address
can
be
used
in
many
cases
as
a
super
cookie
and
we've
seen
people
actually
using
this
in
ad
networks.
P
You
know:
do
I
I
assume
for
either
fraud
protection
or,
for
you
know,
super
cookie
type
mechanisms
and
one
option
could
just
say:
hey.
We
don't
support
this
type
of
behavior.
We're
not
going
to
give
these
addresses
out
to
the
application,
we're
just
going
to
say
hey
whatever
public
interface
public
ip
address.
P
You
get
that's
what
you
have
and
you
you
know
do
with
it
when
you
can,
however,
that
prevents
these
sort
of
land
scenarios
two
devices
being
able
to
connect
directly
within
the
same
local
network
and
reduces
a
lot
of
the
value
of
having
peer-to-peer
connections,
so
we're
trying
to
figure
out
what
to
do
here
next
slide.
P
And
some
folks
at
apple
came
up
with
some
ideas
around
using
md
and
s
to
basically
wrap
these
addresses,
and
this
technique
has
been
deployed
and
actually
works
quite
well
where
upon
getting
the
ip
address.
P
Instead
of
passing
the
ip
address
to
the
application,
you
actually
register
register
an
mdns
name
for
maps,
one
to
one
to
the
ip
address,
and
then
you
pass
the
mdns
name
and
port
through
the
service
up
to
the
application
and
then
upon
reaching
the
other
side,
the
other
side.
If
it's
on
the
same
local
area
network
will
be
able
to
resolve
the
mdns
address,
find
the
ip
and
then
the
browser
will
be
able
to
connect
directly
as
before.
But
in
this
case
the
app
has
never
been
able
to
access
the
the
ip
address.
P
So
this
basically
walks
through
the
steps
you
know
every
time
when
it
goes
to
hand
on
ip
address.
It
goes
and
registers
that
name
it
does
this
on
like
a
per
origin
basis,
so
that
these
names
are
not
correlatable,
but
basically
the
the
md
s
address
serves
as
a
wrapper
for
the
ip
and
if
the
other
side
happens
to
be
on
the
same
network,
it
can
resolve
it,
and
if
it
wasn't
able
to
resolve
it,
then
the
ip
address
probably
is
not
reachable
anyway,
so
it
actually
works
out
quite
well
in
practice.
P
P
So
you
know
the
easiest
way
to
think
about.
This
is
that
the
mdns
is
essentially
a
wrapper
function
and
like
wrapping
it.
You
know
with
a
sort
of
pseudo
key
where
the
key
is
basically
the
fact
that
they're
on
the
same
network
segment-
and
you
know
the
mdns
technique-
can
allow
it
to
resolve
or
unwrap
the
mdns
address
back
to
a
plain
ip.
P
You
know
there
are
some
cases
where
mdns
is
not
supported
and
we
try
to
figure
out
what
can
be
done
in
those
cases,
and
one
potential
opportunity
here
is
to
use
a
key
distributed
through,
say,
chrome,
enterprise
policy
dhcp
to
basically
allow
this
wrapping
to
be
done
using
the
straight
encryption
rather
than
using
mdns,
and
still
have
this
property,
where
the
browsers
can
have
their
ips
directly.
But
the
application
only
gets
the
obfuscated
or
wrapped
ips.
P
But
this
has
been
a
pretty
critical
technique
to
webrtc
sort
of
working
well
on
on
lands
and
then
also
having
this
property
that
we
know
we're
not
giving
up
any
additional
ip
addresses.
That
would
not
be
otherwise
available
to
the
app
and
that's
all,
there's
some
links
there
to
the
documents
for
both
mdns
candidates
and
to
additional
work
on
encrypted
eyes
candidates.
P
A
A
Questions:
okay,
if
not
that
was
super
quick.
Thank
you
for
going
through
it
and
if
you're
interested
in
the
design
can
check
out
the
links
here.
A
Oh
sorry,
I'm
sorry,
I
didn't
scroll
down,
go
ahead,
dave.
L
P
If
you
have
an
eavesdropper
on
the
land,
they
can
see
a
given
endpoint
registering
an
mdns
address.
You
know
for
a
given
ip,
you
know,
and
if
that
was
a
molecular
sort
of
eavesdropper
and
was
trying
to
broadcast
information
publicly,
then
it
would
allow
somebody
to
you
know
do
that
unwrapping,
but
you
would
basically
need
to
have
collusion
between
you
know
the
application
that's
running
on
or
in
the
browser
and
in
this
sort
of
endpoint
that
happens
to
be
embedded
in
the
in
the
lan
and
sims
mdns
queries.
A
You're,
muted,
I
don't
I
you
seem
to
be
talking
about
your
muted
yeah.
There
you
go.
I
Sorry
I
haven't
been
following
the
web
rtc
work,
but
you
know
from
your
presentation.
You
know.
I
understand
that
in
cases
where
mdns
is
not
available,
there
might
be
challenges
with
you
know,
setting
up
a
domain
name,
but
it
would
seem
to
me
that
web
rtc
dealing
with
domain
names
from
an
architectural
point
of
view,
is
the
right
thing,
as
opposed
to
be
dealing
with
ip
addresses,
not
just
for
the
privacy
reason
that
you
mentioned.
But
you
know
from
other
perspectives
as
well.
P
Yeah
I
mean
like
it's
nice
if
it's
possible.
The
problem
is
that
since
peers,
don't
typically
have
domain
names,
you
know
establishing
that
level.
Latency
peer-to-peer
connection
is
challenging
unless
you
have
like
this
just-in-time
registry,
as
might
happen
here
with
with
mdns.
I
Like
you
know
it's
like
I
mean
I
don't
want
to
start
that
debate,
but
it's
like
you
know
when
people
argue
that
you
know
nuts
are
breaking
all
these
things
and
many
of
the
things
that
get
broken
is
that
because
you
are
doing
them
the
wrong
way,
that's
what
I'm
saying
so
yeah
you
know
the
dns
stuff
that
is
missing,
and
that
is
challenging,
and
you
know
I
understand,
and
actually
I
I
agree
with
that.
What
I'm
saying
is
that
it
probably
brings
up
something
that
maybe
we
should
be
doing
something
that
we
are
not.
I
So
that's
probably
an
opportunity
like
saying
well,
if
we
wanted,
for
example,
to
be
dealing
with
domain
names,
probably
you
know
we
should
find
a
way.
You
know,
for
example,
by
which
hots
could
be
able
to
get
a
domain
name
to
use.
I've
seen
all
the
cases
where
you
know
this
kind
of
thing
would
be
necessary
and
they
face
the
same
challenge
and
the
same
problem.
P
Okay,
I
mean
it'd
be
interesting
to
see
if
there
were
similar
problems
that
were
solved
through
this.
You
know.
The
concern,
of
course,
is
always
that,
if
you
add
in
a
registry,
that's
another
single
point
of
failure
that
has
to
be,
you
know,
dealt
with
as
part
of
the
the
setup
sequence
which
could
be
quite
challenging.
A
All
right,
thank
you,
justin,
especially
if
you're
going
through
that
so
quickly.
Next
up
and
last
up
is
brad
brad.
How
do
you
want
to
proceed?
You
want
me
to
share,
or
can
you
share.
A
B
All
right,
those
coming.
B
B
B
So,
just
as
way
a
background
work
on
the
project,
sandbox
with
chrome
first
step
is
separating
cookies,
but
we
need
to
address
all
the
other
mechanisms
for
identity
linking
including
ip.
B
There
are
effectively
three
ways
to
address
privacy
with
ip
addresses
wants
to
give
one
person
many
addresses,
for
instance,
one
per
tab,
another
one's
to
give
many
people
one
address,
and
the
third
is
to
make
servers
not
use
ip
addresses
for
identity,
that
first
option
or
slides
aren't
dancing
right
now.
We
we
found
out
as
fernando
was
talking
about
with
slack
giving
one
person
one
one.
B
B
B
B
Nat,
recognizing
that
the
the
the
audit
mechanism
would
be
rather
cumbersome
to
a
lot
of
players
on
the
web,
such
that
as
an
alternative
for
most
of
the
web,
something
along
the
lines
of
near
pathmat
where
we
can
nat
at
the
cdn
level,
at
the
edge
close
as
close
to
the
browsers
and
as
close
to
the
path
of
observing
as
possible,
putting
a
privatizing
server
there
and
have
users
that
are
geo
located
close
to
each
other
using
the
same
server
such
that
a
lot
of
the
concerns
are
still
addressed
using
this
mechanism
in
order
to
support
ip
some
of
the
anti-abuse
work.
B
A
couple
of
things
are
presented.
The
ip
addresses
remain
stable
for
each
first
party,
so
a
browser
tab
to
example.com
any
browser
tab
to
poster.com
would
have
separate
addresses.
But
if
I
revisited
example.com,
I
would
get
the
same
ip
address
port
tuple
as
before.
B
Yes,
let
me
see
so
here's
a
diagram
how
this
would
work.
You
basically
have
hp3
session
to
the
ip
privatizer
and
it
would
hand
out
separate
ip
addresses
going
to
each
of
the
servers
by
being
near
path.
We're
you
know
not
altering
the
path
of
the
overall
connection
and,
hopefully
being
rather
efficient
with
performance.
B
I
talked
about
the
guip
and
talked
about
how,
by
by
giving
these
stable
ip
addresses
for
a
client
and
top
level,
most
of
the
anti-abuse
mechanisms
for
first
parties
still
work,
the
thought
being
that
the
that
a
large
third
parties
would
be
able
to
use
the
wolf
life
blindness
and
most
first
parties
would
be
able
to
rely
on
the
near
path
not
proposing
using
the
the
mask
work,
which
is
already
underway
at
the
ietf
as
the
overall
mechanism
for
doing
this
proxy,
and
that
is
a
very
short
overview.
B
I
hope
to
give
a
deeper
dive
later.
A
Yeah
great,
thank
you
for
accommodating
the
short
amount
of
time.
Brad.
Obviously,
there's
a
lot
to
unpack
here,
and
hopefully
we
can
get
to
that
in
the
next
meeting.
With
a
high
priority
talk
with
the
cube,
we
probably
have
time
for
like
very
one
very
quick
question
before
we
wrap
up,
discuss
next
steps
so
christian,
why
don't
you
take
it
away.
G
Yeah,
that's
an
interesting
idea
and
it
meets
a
lot
of
the
requirements
there's
something
about
who
pays
for
the
new
night,
and
I
guess
we
can
discuss
that
later.
But
I
have
a
question
about:
isn't
there
a
tension
between
the
desire
to
have
your
proxy
close
to
the
user
for
performance
reason
and
the
size
of
the
anonymity
pool
that
you
get.
B
Yes,
but
if
you
think
about
most
cdn
edge,
caches
are
designed
to
serve
at
least
a
useful
set
of
people.
There
is
there's
cost
associated
with
those
servers
so
that
that
seems
like
a
the
right
balance
of
the
mapping
of
the
number
of
users
are
being
being
served
by
a
particular
node
and
giving
those
users
some
amount
of
privacy.
B
Yep
needs
to
be
explored
further.
A
All
right,
fernando,
is
it
quick
because
we're
right
at
the
end.
I
Yeah,
so
my
comment
is
that
you
know
I
have
concerns
with
this
idea
of
trusted
servers
and
trusted
providers
like
there
is
an
assumption
that,
for
some
reason,
the
user
that
wants
privacy
for
some
reason
has
to
trust
the
company
or
or
an
organization
and
all
specific
names
aside.
You
know:
that's
not
the
strategy
that
I
would
follow
for
the
sake
of
privacy,
so
I,
like
the
you,
know
whatever
privacy
strategy
that
I
have
that
relies
on
not
trusting.
Whoever
else
I'm
supposed
to
be
trusting
or
I'm
usually
trusting.
That's
it.
N
A
All
right,
thank
you,
so
that
about
wraps
it
up.
Two
next
steps:
I'd
like
to
have
a
meeting
in
itf
110,
again
to
sort
of
continue
this
topic
and
and
do
a,
I
guess,
a
more
in-depth
debrief
in
terms
of
what
we
discussed
here.
I
think
there
are
a
number
of
important
topics
that
were
discussed
today
around
iq
reputation
around
you
know
emerging
technologies
like
mask
and
privacy
paths
and
how
they
might
benefit
through
the
ip
address
privacy
situation
on
the
web.
A
So
if
you
are
curious
in
those
technologies,
I
encourage
you
to
check
out
the
working
groups
that
are
going
to
hold
meetings
at
one
time
and
also
subscribe
to
the
mailing
list
and
check
them
out.
I
don't
know
sarah
siobhan.
Do
you
wanna,
add
anything
before
we
conclude.
C
Just
to
say,
thanks
again
to
all
our
presenters
for
great
presentations
today
and
yeah,
I
think
there's
a
lot
of
follow-up
work.
We
can.
We
can
look
at
here
on
a
variety
of
topics,
so
we
will
follow
up
on
the
list
tomorrow
with
a
brief
overview
of
her
plan
moving
forward.
But
if
you
have
any
specific
ideas
about
pieces
of
work,
please
do
write
to
the
list.
A
Also,
thank
you
ben
for
taking
notes.
They
are
extremely
thorough
and
will
undoubtedly
be
very
helpful
in
the
future.
So
special,
thank
you
to
you
and
with
that
we
can
call
it.
Thank
you
all
and
enjoy
the
rest
of
your.