►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
essentially
I
wanted
to
talk
a
bit
about
content,
negotiation
and
client
hints
I've
been.
This
is
a
project
that
I've
been
involved
with
for
many
years.
I've
also
been
involved
with
the
working
group
for
many
years,
but
for
some
reason
those
two
worlds
never
collided.
So
I
wanted
to
just
talk
to
the
working
group
about.
A
That
that
feature
and
content
negotiation
in
general
and
yeah
and
see
what
you
all
think
so
try
to
gather
opinions
so
content
negotiation
is
a
thing
and
by
content
negotiation
I
mean
responses
that
the
server
adapts
to
specific
characteristics
of
the
request
that
go
beyond
just
its
url.
A
We
have
multiple
headers
in
in
multiple
request:
headers
that
are
being
used
for
content
negotiation.
We
have
accept,
which
is
essentially
sending
out
the
supported
file
types
and
enabling
the
server
to
serve
different
file
types
for
different
browsers,
depending
on
their
support
levels
except
encoding.
That
accepts
different
compression
algorithms
on
the
wire,
and
we
talked
about
that
a
bit
in
the
context
of
that
standard.
A
The
other
day
we
have
the
user
agent
string,
which
is
yeah
a
very
heavy
hammer
that
is
being
used
for
content
negotiation
for
many
many
different
things
and
yeah
is
typically
not
I
I'm
not
a
huge
fan
and
finally,
there's
also
accept
language
which
adapts
the
site's
content
content
to
the
user's
language.
When
one
is
set.
A
I
may
be
leaving
out
a
few
here,
but
I
think
I
covered
all
of
them,
but
I
may
be
leaving
out
things,
there's
also
other
forms
of
content,
negotiation
that
are
geographically
based
or
not
like,
based
on
other
characteristics
such
as
you
know,
the
user
is
coming
from
europe,
so
let's
send
them
to
the
whatever
you
know,
a
different
page
with
a
different
like
with
different
characteristics.
A
Those
are
out
of
scope
for
this
discussion,
but
yeah.
It's
a
thing
that
happens
at
the
same
time.
Passive
fingerprinting
is
also
a
thing
and
all
that
information
or
a
lot
of
information
that
those
headers
expose
is
also
information
that
can
be
used
for
passive
fingerprinting
by
splitting
out
users
and
yeah,
enabling
servers
to
tell
those
users
apart
without
having
to
do
anything
about
it.
A
So
the
servers
can
just
observe
the
information
being
sent
to
them
and
then
use
that
to
fingerprint
users,
and
that
is
opposed
to
active
fingerprinting,
which
is
a
detectable
act
where
the
server
actively
asks
for
information
and,
for
example,
if
a
server
asks
for
a
lot
of
information
that
can
be
used
for
fingerprinting.
That
is
something
that
security
and
privacy
researchers
can
spot.
That
is
something
that
browsers
can
spot
and
do
something
about
so
yeah.
Passive
fingerprinting
is
yeah
bad.
A
So
that
brings
us
to
client
hints.
Client
hints
is
essentially
a
content
negotiation
mechanism
that
limits
the
amount
of
information
sent
by
default
and
significantly
therefore
limits
passive
fingerprinting
and
asks
for
specific
server,
opt-in
for
information
it
needs
in
order
to
perform
content
negotiation
that
has
a
privacy
advantage.
It
also
has
a
correctness
advantage
of
tying
the
information.
The
server
needs
to
the
information
that
it
requests,
rather
than
using
various
proxies
to
make
assumptions
that
may
or
may
not
be
correct.
A
The
essential
mechanism
for
client
hints
is
the
client
sends
out
a
request.
The
request,
the
initial
request
to
the
server
doesn't
contain
any
of
the
high
entropy
client
hints.
It
may
contain
some
low
entropy
hints
that
are
sent
by
default.
The
server
then
asks
for
specific
high
entropy
hints.
A
One
example:
is
you
know,
device
memory
here
as
a
response
header?
There
are
many
others
we'll
talk
about
them
in
a
bit
that
opt-in
is
persistent
for
the
browser
session
and
then
following
requests
contain
those
requested,
hints
and
yeah
and
send
out
those
values
to
the
server
and
the
server
can
do
a
content
adaptation.
Based
on
that
that
works
great
for
sub
resources.
A
It
works
less
great
for
navigation
responses.
It
is
not
sent
to
cross-origin
contexts
by
default
and
nor
to
cross-origin
in
general
and
sending
those
hints
to
cross
origin.
I
should
have
written
that
down,
but
it
requires
a
permission
policy
based
delegation,
two
specific
cross,
so
the
top
level
origin
needs
to
delegate
that
information
to
other
origins.
If
it
wishes
to
do
that,
then
we
have
in
order
to
resolve
the
very
first
request
issue.
We
have
a
related
proposal.
A
That's
called
client
hints
reliability
where
we
have
a
parallel,
critical
ch
response
header
that
essentially
says
that
the
origin
prefers
or
redirect
over
getting
the
response
wrong.
That
is
unimportant
like
it's,
not
something
you
would
want
to
do
for
optimization
purposes,
but
it
is
something
that
is
important
for
correctness
issues
and,
for
example,
for
like
this
is
with
the
user
agent
bits
where.
A
Origin,
like
more
servers,
can
send
the
wrong
content
if
they
get
it
wrong.
A
They
want
to
be
sure
that
you
know
that
they
avoid
correctness
issues
even
in
the
price
of
a
redirect
and
then
the
second
proposal
called
alps
and
an
except
chdp
frame,
which
is
essentially
performing
the
client
hints
opt-in
as
part
of
the
h2
or
h3
connection
establishment,
phase,
effectively,
stealing
an
rpt
and
avoiding
the
need
for
a
redirect
so
performing
that
opt-in
before
the
very
first
request
is
ever
sent
so
in
terms
of
privacy
considerations.
A
Information
exposed
with
client
hints
is
information
that
should
be
regarded
as
active
information
exposure
because
it
requires
an
opt-in
and
the
browser
can
also
refuse
to
send
that
information
or
you
know,
lie
in
weird
cases,
although
that's
not
something,
that's
currently
happening
yeah,
so
the
at
least
the
high
entropy
hints
are
active
information.
The
low
entropy
hints
continue
to
be
passive
information,
but
it
is
information
that
is
useful
or
like
low
entropy
enough
for
to
justify
that
it.
A
One
principle
we
kept
is
that
we
don't
expose
anything
that
is
not
already
exposed,
otherwise,
either
through
javascript
apis
through
html,
for
example,
set
or
through
css,
for
example,
media
queries-
and
there
are
a
bunch
of
client
hands,
features
that
rely
on
that
infrastructure
for
responsive
images.
We
have
information
about
the
screen,
dpr,
so
device
pixel
ratio,
viewport
width,
viewport
height,
which
is
a
recent
edition
still
being
experimented
with.
A
As
far
as
I
remember
and
the
width
of
an
element
that
is
specific
to
images
in
when
certain
conditions
apply,
we
have
the
user
agent
client
hints
that
ex
essentially
break
apart
the
current
information
exposed
by
the
user
agent
string
into
various
fail
fields.
Some
have
more
entropy
than
others,
and
those
fields
can
then
be
requested
and
potentially
get
get
that
information
or
not,
depending
on
whether
it's
already
exposed
in
the
user,
agent
string
or
not,
network
information
is
something
we
talked
about
a
few
weeks
back.
A
Thomas
has
a
proposal
to
revamp
those
values,
but
right
now
it
exposes
effective
connection,
type,
download
and
rtt,
and
we
have
a
few
more
device
memory,
which
is
which
the
working
group
is
working
on,
save
data
and
prefers
color
scheme.
That
thomas
will
talk
about
in
a
bit
and
then
finally,
I've
been
thinking
about
the
accept
header
and
ways
to
fix
that.
A
Right
now
accept
is
getting
longer
and
longer,
as
we
add,
various
format,
support
and
that
results
in
course,
restriction
violations
it
just
in
terms
of
its
length,
because
cores
has
a
length
like
per
header
length
restriction.
It's
also
bad.
So
for
one
recent
example
that
came
up
font
content,
negotiation
typically
happens
in
the
css
itself,
because
for
different
fonts
you
need
to
change
the
css
that
calls
into
them.
A
At
the
same
time,
there
are
properties
that
want
to
be
able
to
have
dedicated
dedicated
css
per
font
technology,
for
example,
so
for
like
new
and
exciting
font
formats,
they
want
different
css
and
that
can
get
hefty
and
they
don't
want
to
deliver
that
unless
needed.
But
there
is
no
reasonable
support
for
accept
and,
like
the
font.
Formats
supported
by
the
browser,
is
not
something
that
the
request
for
the
css
knows
by
its
accept
header,
because
it's
not
css
support.
A
It's
font
support,
so
it's
indirect
and
therefore
not
exposing
except
right
now,
and
it
would
be
wasteful
to
just
expose
it
for
all,
accept,
headers
or
all
except
headers
with
the
for
css.
It
would
have
like-
or
at
least
it
would
be
weird-
and
it
may
be
better
to
try
to
fix
that
with
client
hints,
where
the
server
explicitly
indicates
which
format
it
is
interested
in
supporting
and
then
the
client
indicates
that
support
or
lack
thereof
through
client
hints,
that's
just
a
thought
for
the
future.
A
A
Whether
any
of
the
specific
features
are
things
that
may
be
interesting
or
useful
and
generally
just
gather
your
thoughts.
So
I
will
stop
talking
now
and
we
can
move
on
to
the
discussion
and
this.