►
From YouTube: WebPerfWG call - May 19th 2020
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
A
A
B
A
A
Otherwise,
I
wanted,
like
we
have
a
list
of
issues
that
we
can
go
through,
but
I
wanted
first
to
talk
about
an
issue.
That's
related
to
a
couple
of
those
issues.
Last
week
we
talked
about
resource
timing,
issues
222
and
223,
or
we
didn't
really
talk
about
them,
but
we
almost
discussed
them
and
we
discussed
them
previously
and
I
think
that
we
need
to
somehow
better
categorize
the
types
of
information
that
resource
timing
is
exposing
and
see
what
different
opt-ins
fit
for
different
types
of
information.
A
So
resource
timing,
information
types:
basically,
we
have
resource
timing
that
historically
only
exposed
timing
information.
A
We
have
the
diagram
here
that
includes
all
the
different
types
of
timing:
information
that
it
exposed.
We
have
a
bunch
of
feature
requests
for
processing
time
that
people
want
us
to
expose
in
the
future.
We
are
also
already
somewhat
exposing
that
through
element
timing
in
a
way
that
is
also
you
know,
expo
exposes
timing,
information
and
the
sensitivity
of
this
information
varies.
A
From
my
perspective,
the
DNS
and
TLS
portions
are
not
really
exposing
anything
that
is
user
specific.
It's
not
really
exposing
anything
that
is
tied
into
the
particular
users,
interaction
with
that
origin.
It
can
expose
details
about
the
users
network
status,
but
that
information
is
also
exposed
elsewhere.
A
So,
from
my
perspective,
the
most
sensitive
bits
here
regarding
timing
information
are
the
time
to
first
byte
that
can
expose
the
time
that
it
takes
the
back-end
server
to
process
requests
for
this
particular
user
and
then
client-side
processing
time.
That
may
be
different
for
different
responses
and
can
expose
details
about
the
user.
A
Then
we
also
have
something
that
was
added
resource
timing,
l2.
We
have
sizing
information
so
encoded
by
the
size,
decoded
buddy
stars
transfer,
size
and
all
those
deep
all
those
information
types.
Look.
This
type
of
information
exposes
details
about
the
user
through
the
content
that
they
load.
So
if
we
have
content
which,
with
varying
sizes
based
on
user
based
on
the
user's
credentials,
this
runs
a
risk
of
exposing
that,
mostly
through
transfer
size,
and
we
talked
about
other
issues
with
the
fact
that
this,
for
example,
exposes
the
headers
and
things
along.
Those
lines
were
exposing.
A
A
This
at
least
the
way
that
I
see
it
will
no
longer
be
sensitive
information.
So
once
all
modern
browsers
will
have
double
keyed
caches,
then
exposing
this
caching
information
would
theoretically
not
require
any
kind
of
up
there.
Now
I
should
caveat
all
that.
Just
saying
that
this
is
my
personal
opinion,
with
my
editor,
like
resource
timing,
editor
hat
on
not
this
is
not
necessarily
something
I
ran
by
Google
or
Chrome
security.
Folks,
it
will
definitely
be
something
that
will
run
by
them,
but
it's
not
yet
an
approved
opinion.
B
A
Yes,
so
double
keyed
caches
will
mean
that
a
URL
is
cached
based
on
its
own
URL,
as
well
as
the
URL
of
the
top-level
domain
of
the
site
that
loaded
it.
So
if
I
am
loading,
a
URL
unloading,
third
party
comm
from
example.com
and
then
I'm
loading,
this
same
third
party
comm
from
food
comm,
the
second
load
will
not
come
from
the
cache,
because
the
cache
key
would
be
different
in
those
two
instances.
A
A
A
At
the
same
time,
maybe
we
can
start
thinking
of
replacing
those
protocol
or
protocol
information,
which
is
mostly
useful
to
detect
problems
or
reveal,
but
basically
av-test
migrations,
so
make
sure
that
the
new
protocol
is
better
than
the
old
protocol.
Maybe
this
is
something
that
can
be
tackled
with
server
timing
instead
or
otherwise.
A
A
A
My
quest
commented
here
that
it
might
be,
and
at
the
very
least,
we
need
to
make
sure
that
we
don't
expose
post
redirect
URLs
we
currently
don't.
We
need
to
make
sure
that
we
still
don't
after
this,
like
potentially
adding
initiator,
but
my
current
assumption
is
that
this
doesn't
necessarily
require
any
opt-ins
from
the
content
itself
and
then,
finally,
we
have
feature
requests
for
status
code
and
content
type,
which
seem
to
expose
direct
information
about
the
response,
which
is
sensitive
information,
as
it
can
reveal
details
about
the
user.
If
the
content
is
credentialed.
A
Yeah
and
then
finally,
we
have
a
proposal
from
Nick
about
enabling
automatic
reporting
of
a
frame
to
its
parent
regarding
its
various
resource
timing
entries.
That
seems
like
something
that
is
quite
different
and
will
require
a
separate
up.
Then,
okay,
so
let's
talk
a
bit
about
the
opt
ins
that
we
currently
have
it
our
disposal.
We
have
timing,
allow
origin
that
we
are
currently
using
for
all
those
types
of
information
that
we
consider
sensitive.
A
A
So
from
my
perspective
and
the
way
that
I
wouldn't
like
to
bucket
those
different
types
of
informations
and
map
them
to
those
different
options,
is
that
timing.
Allow
origin
is
something
that
only
bars
timing
or
timing
information
and
not
much
else
so
that
it
will
enable
us
to
receive
to
to
expose
the
time
to
first
byte
the
exposed
at
processing
time,
as
well
as
the
DNS
and
TLS,
but
not
other
types
of
information,
and
as
far
as
developer
advice
goes,
it
seems
that
it's
perfectly
safe
to
turn
on.
A
Then
we
have
cross
foraging
resource
policy
which
it
seems
like
it's
okay
for
to
expose
sizing
information.
We
are
talking
about,
for
example,
making
the
measure
memory
API
barred
on
Corp
being
enabled
so
in
that
world
it
seems
reasonable
to
also
say
that
sizing
information
will
be
barred
on
that
same
optin.
A
The
split
of
information
types
into
those
separate
opt-in,
buckets
and
whether
it
makes
sense
both
from
a
privacy
and
security
standpoint,
as
well
as
from
a
developer
ergonomics
standpoint
I,
would
love
to
hear
thoughts
on
both
those
fronts.
D
E
A
For
my
perspective
course,
the
course
check
either
passes
or
fails.
If
the
course
check
failed,
then
you
know.
Of
course
that's
failed
like
if
course
failed,
but
timing
allow
origin
passed.
Then
that
means
we
can
expose
the
timing
information,
but
not
more
than
that.
If
timing
allow
origin
failed,
but
course
passed,
I
think
that
it's
a
sense
it's
safe
to
read
the
resource.
It's
also
safe
to
expose
that
information,
so
I,
don't
really
basically
I
the
way
that
I
see
it
and
folks
may
disagree.
F
Does
that
make
sense,
I
think
it
does
your,
but
how
do
we
take
you
know?
How
do
we
explain
our?
Let
the
you
know?
Let
the
community
understand
everything
like
you
have
a
beautiful
presentation.
You
explain
it
correctly
like
the
different
priority
and
the
one
that
oversees
the
over.
You
know
that
superior
to
the
other
policy,
but
I'm
just
trying
to
find
like
how
can
we
convey
this
disorder
to
two
people?
So
they
understand
because
it
seems
like
you
know
it's
it's
a
little
bit
complicated.
F
A
A
I,
don't
know
accessible
at
the
same
time.
It's
a
newer
concept,
so
it
will
take
people
some
time
to
get
accustomed
to
that.
I'm,
hoping
that,
because
there
are
a
bunch
of
new
capabilities
that
are
bound
behind
cork,
that
will
enable
or
that
will
motivate
people
to
understand
Corp
beyond
the
just
performance
ad
eyes.
D
A
Yes-
and
this
will
also
require,
if
we
would
go
down
that
path-
I
suspect
that
this
will
give
the
rum
community
a
lot
more
timing,
information
for
a
third
party
content
that
is
course
enabled
or
Corp
enabled,
but
at
the
same
time
some
of
the
information
may
be
lost
in
scenarios
that
are
currently
you
know.
If
the
resource
it
does
have.
Timing
allow
origin
enabled
but
doesn't
have
any
of
the
other
opt-ins.
They
will
lose
the
sizing
information,
for
example
right.
F
I
think
you
are
I,
think
it's
great
to
have
those
buckets.
You
know
like
in
a
way
to
remind
me
when
I
first
learned
CSS
and
there
are
different
rules.
There
are
different
predecessor
if
it's
an
ID
or
class.
If
you
have
the
important
symbol
and
as
a
beginner,
you
don't
really
understand
which
rule
apply
and
then
someone
came
with
nice
way
to
explain
the
algorithm.
You
know,
like
I,
think
use
four
digits,
one
and
zeros
to
understand
which
one
takes
precedence
and
I
think
once
we
have
something
like
that
with
style,
corp
and
cars.
F
So
without
looking
at
the
specs,
we
can
know
which
one
is
going
to
apply
when
one
is
not
specified
will
be,
which
I
think
the
Birkett
idea
is
great,
but
I'm
just
trying
to
see
from
from
here
to
when
I'll
be
able
to
understand,
what's
going
to
happen
or
what
should
happen,
there's
this
kind
of
gap
that
I'm
I
don't
know
how
to
feel
right
now.
You
know
I'm
saying
like
so
so
we
we
can
understand.
What's
supposed
to
happen,.
F
Some
sort
of
again
is
this:
I
think
it's
more
like
in
the
documentation
or
to
me,
I'm,
visual
and
I
would
love
to
see
some
sort
of
table
where
I
can
see
that.
If
one
doesn't
exist,
then
it
moves
to
the
next
column
and
then
okay,
so
this
policy
applies.
So
that's
what's
going
to
happen,
I
mean
in
a
way
like
what
my
Mitchell
asked
before.
F
What,
if
you
know
the
two
conflicts
which
one
takes
precedence
and
you
know
some
sort
of
table
to
quickly
understand
what
would
happen
in
in
all
those
cases,
I
I
to
meet
it's
a
again.
I
love
the
bucket
ID,
but
it
to
me
it's
hard
to
to
know
how
one
day
I'll
be
able
to
explain
to
one
of
my
tier
how
it's
supposed
to
happen.
We
fought
adding
like
a
one
page
where
I'll
see
all
the
different
cases
and
and
understand
what
I'm
supposed
to
see
when
these
police
is
there
or
it's
not
there.
E
Yeah
I
thought
that
separating
it
out
into
buckets
when
you
see
the
three
together
made
a
lot
of
sense
to
me
and
the
way
you
answered
my
question
was
the
right
way
that
I
thought
you
were
implying
where
I'm
concerned
is
it's
not
really
self
documenting
like
if
you
just
like
that,
the
headers
and
you
saw
that
timing
allow
origin
was
not
enabled
you
might've
assume
that
it
won't
be
available.
So
it's
this
implication
that
one
is
thing
but
I
mean
these
things.
Aren't
easy
they're
not
meant
to
be
understood
at
a
glance
and
I.
A
That's
my
hope,
I
think
that
so
yeah.
First
of
all,
it's
a
shame
that
those
are
not
self
explanatory
but
yeah.
That's
effective
life
at
that
point,
yeah
I'm,
hoping
that
we
can
just
use
the
work
that
will
be
done
in
order
to
make
like
make
it
to
clarify
the
relationship
between
cores
and
corpse.
You
also
put
in
tau
into
that
into
the
mix
and.
A
G
They're
close
correct,
but
I
do
I
do
think.
We
generally
agree
with
the
principle
that
if
you
have
access
to
the
content
bytes
then
access
to
the
timing
data
is
less
sensitive
than
that
and
it's
kind
of
implicitly
you're.
Okay
with
that,
and
we
we
make
similar
assumptions
with
our
WebRTC
access
policies.
And
so
you
know,
if
you
have
access
to
the
camera,
then
you
know
you
also
have
access
to
the
microphone.
G
That's
fine
and
yeah
I
like
helping
people
to
understand
that
that's
the
principle
this
is
based
on
and
then
you
know
have
have
tables
for
the
Nerds,
but
yeah
I.
Think
that's
fine.
The
the
only
detail
about
this
that
I
kind
of
disagree
with
is
the
exposure
of
the
timing
data
and
the
DNS
data
in
particular
like
I.
Don't
think,
there's
a
way
to
view
DNS
timing
data
as
well
as
the
browser
can
expose
it
so
for
DNS,
but
that's.
E
G
A
G
A
A
A
A
A
A
A
Hello,
hey:
you
dropped
off.
We
were
talking
about
earlier
issue,
but
it
seemed
editorial.
So
we
moved
fast
it
we're
now
talking
about
navigation
timing,
issue
125,
where,
if
I
understand
correctly,
we
need
a
realm
in
order
to
create
the
navigation
timing
entry
at
the
same
time
it
may
be
created
before
the
document
exists
so
specifying
the
realm
may
be
tricky.
C
A
A
A
Yeah
I
can
I'm
not
sure
yeah,
okay,
okay
cool
the
solution.
You're
proposing
here
sounds
good
to
me.
I
actually.
G
Had
a
quick
question
about
this,
one
I
was
recently
looking
into
our
implementation
of
the
performance
navigation
timing
stuff,
and
would
it
be
against
the
specification
if
we
move
to
the
availability
of
that
timing
until
after
the
main
resource
had
completely
finished
loading.
D
A
A
A
A
A
C
A
Yeah,
so
my
thinking
is
that
yeah
network
error
logging
can
resolve
the
you
know
400-500
case,
but
maybe
the
use
case
goes
beyond
that.
So
I
can
yeah.
I
can
take
an
action
item
to
try
to
drill
further
and
ask
more
questions
about
the
use
case
to
see.
If
this
is,
you
know
a
valuable
feature
request
or
something
that
Network
error
logging
should
so.
A
Not
sure
and
you
yeah
you're
saying
maybe
there
is
a
case
for
being
able
to
teleport
your
five
hundreds
from
your
two
hundreds
yeah.
D
Yeah
absolutely
so:
we've
actually
had
a
from
Menachem
ice
perfect.
So
we've
had
a
bunch
of
customers,
ask
to
be
able
to
report
on
what
their
customers
are
seeing
for
error
pages
and
such,
and
so
we
go
through
all
these
hoops
to
kind
of
round-trip
the
status
code
through
the
HTML
and
stuff
like
that,
because
I
want
to
measure
the
performance
or
measure
how
often
it
happens
or
what
have
you
and
well
network
error
logging
helps
in
some
ways
it's
hard
to
tie
it
directly
to
the
user
in
some
cases.
D
So
if,
like
you,
have
a
user
navigating
through
a
site
and
then
you
know
they
have
a
session
ID
or
cookie
or
something
you
lose
that
as
part
of
network
error
logging,
often
because
it's
hard
to
transport
that
with
the
network
error
log.
So
it
could
be
helpful
to
see
these
kind
of
bumps
in
the
road
via
rum.
If
that
data
was
part
of
it
now
this
may
be
more
just
appropriate
to
solve
in
resource
diving
and
then.
D
A
Other
complications
regarding
the
opt-in
right,
which
navigation
timing
doesn't
have
yeah
yeah,
but
generally
I
think
this
is
generally
an
l-3
question.
But
if
you're
saying
this
is
a
use
case,
you
have
also
run
okay.
Then
maybe
you
can
comment
on
that
issue
clarifying
that
and
then
we
can.
You
know,
label
it
as
a
feature
request
for
Ellsbury
I
will
do
top
yep
cool
thanks.
Awesome.
A
Allow
performance
that
measure
to
specify
a
caller
parameters
for
performance,
visualizations
and
dev
tools.
That's
a
tricky
one,
cuz
yeah
I
think
we
don't
have
other.
Like
any
other.
A
E
So
I
just
issue:
some
idea
that
comes
quickly
to
mind
is
to
look
at
console
logging
and
there's
a
bunch
of
ways
to
decorate
console
log
messages.
I,
don't
know
how
standardized
those
are
or
how
much
those
are
based
on
conventions
for
the
particular
browser
and
dev
tools.
But
one
of
the
suggestions
here
was
just
to
use
the
detail.
Tab
and
like
each
dev
tools,
provider
will
publish
their
own
conventions
as
opposed
to
standardizing
them.
A
A
Yeah,
it
might
be
interesting
to
loop
in
chrome,
dev
tools,
folks,
as
well
as
you
know,
Safari
dev
tools,
folks
the
Firefox
slip
tool
folks
and
see
what
would
be
like
from
their
perspective.
What
would
be
the
best
way
for
those
different
measures
to
be
marked?
Alternatively,
we
can
also
think
of
like.
A
A
Yeah
I
I
think
I
can
I
can
take
an
action
item
to
loop
in
the
chrome,
dev
tools.
Folks
Alex,
could
you
try
to
loop
it
in
Safari,
dev
tools?
Folks
onto
that
thread
and
see,
you
know
see
what
they
say
in
terms
of
passing
along
that
information
from
developers
to
the
console
or
to
the
reader
tools.
G
A
Thank
you,
I,
for
what
it's
worth
I
agree
with
the
strangeness,
but
maybe
there
are
already
channels
for
developers
to
do
those
sort
of
things
or
maybe
there's
you
know
the
site
will
provide
the
different
marks
and
measures
and
then
they
will
can
have
a
console
command
that
can
somehow
you
know
collar
them
in
different
ways.
I
don't
like
I,
don't
know,
but
it
seems
like
they
would
have
ideas
on
that
front
that
we
like
I
at
least
don't.
E
This
one,
just
as
for
food
for
thought,
it
looks
like
the
console,
API
supports,
passing
CSS
properties
and
then
the
browser
vendors
list
out,
which
particular
properties
they're
willing
to
accept
and
I.
Don't
it's
not
the
full
set
of
CSS,
but
they
borrowed
an
existing
thing
that
developers
are
comfortable
with,
so
you
have
the
font
style
and
color
and
background
color
etc.
So
all
you
need
to
standardize
is
how
you
provide
your
list
of
props
and
then
the
props
get
handled
in
a
browser
specific
way.
H
A
H
Heard
when,
when
I
I
talked
to
them,
that
I
understood
it
but
like
if
you
read
the
comments
from
my
be
Gerard
III
think
they
actually
do
just
not
want
to
spam.
The
performance
timeline
so
much.
It
was
in
in
Chrome's
accommodation
where
it
was
too
slow
and
we
fixed
that.
So
there's
a
couple
of
different
issues
conflated
here:
okay,.
C
A
H
A
Yeah
I
will
so
I
will
take
an
action
item
to
read
through
this
and
potentially
also
loop
in
the
dev
tools
folks
and
see
it's.
This
is
something
that
we
actually
want
to
provide,
but
it
feels
yeah
I
tend
to
agree
with
Nikolas
that
this
is
like,
potentially
best
implemented
in
userland,
rather
than
having
the
browser
provide
that
you
know
option
to
turn
off
marks
that
are
being
called
by
the
developer.