►
From YouTube: WebPerfWG TPAC 2020 meetings - October 22 - part 1
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
hello
and
welcome
to
the
fourth
day
of
tpack's
web
performance
working
groups
festivities.
As
always,
this
call
is
being
recorded
and
will
be
posted
online
and
today,
on
the
agenda.
We
have
a
few
things.
First,
I
I
want
to
talk
about
unifying
the
various
opt-ins
or
at
least
rationalizing
the
various
opt-ins
that
we
have
for
timing,
allow
origin
course
and
corp,
then
ian
will
provide
us
with
an
update
on
the
reporting
api,
and
then
I
will
talk
about
some
ideas.
A
I
have
around
a
reporting
api
and
actually
recording
performance
metrics,
but
let
let
me
start
by
sharing
my
screen
and
talking
about
opt-ins.
Also,
we
have
on
the
call
a
few
folks
from
webup
sex,
so
be
nice
to
them,
and
we
also
want
to
maybe
introduce
yourselves
while
I'm
figuring
out
the
screen
sharing
bit.
D
E
A
Cool,
so
what
is
the
problem
with
opt-ins?
Generally,
we
have
a
lot
of
them.
They
are
not
well
layered
and
as
web
developers,
I
think
it's
unclear
which
opt-ins
should
fit
where
and
for,
for
example,
for
public
resources
that,
where
all
the
opt-ins
should
apply
today,
web
developers
need
to
set
all
of
them.
A
So
the
current
state
is
that
we
have
too
many
opt-ins
and
it's
just
somewhat
of
a
mess
and
when
I'm
talking
about
opt-ins,
I'm
talking
about
timing
and
law,
origin,
cross-origin,
resource
policy,
so
corp
with
its
friends,
co-app
and
generally
we'll
talk
about
cross-origin,
isolated
contexts,
and
then
we
have
the
cross-origin
resource
sharing
that
we
all
know
and
love.
A
There
are
various
information
types
that
we've
talked
about
in
the
working
group.
Before
for
timing
related
information,
we
have
resource
level,
resource
level
timing,
so,
for
example,
response
start.
We
have.
A
We
have
origin
level
timing,
so
various
things
that
are
related
to
the
connection
and,
for
example,
to
worker
start
that
essentially
provide
us
with
origin
level
information,
but
with
timing
of
our
origin,
every
resource
is
allowed
to
provide
that
and
then
finally,
we
have
user
network
level
information
which
includes
dns
related
information
as
well
as
next
hop
protocol,
which
we
have
a
bunch
of
issues
that
are
discussing
that.
A
Then
we
have
various
entries
in
resource
timing
that
expose
the
resource
size.
So
we
have
transfer
size,
encoded
body,
size,
decoded
body,
size
and
resource
size
is
somewhat
of
a
sense
like
it's
somewhat
sensitive
information,
because
it
is
used
in
many
cross,
origin
leaks
and
then,
finally,
we
have
caching
information
that
is
also
being
exposed
by
transfer
size,
because
that
size
is
zero
when
the
resource
is
cached.
A
A
One
is
resource
metadata,
such
as
http
status
code
and
content
type
information
that
is
not
currently
exposed
in
resource
timing,
and
then
we
have
desire
to
have
some
opt-in
for
frames
to
report
various
timing
entries
to
their
parents
and
that
yeah.
So
that's
another
type
of
information
that
you
may
eventually
wanna
expose
so
a
concrete
proposal,
since
we've
discussed
all
these
in
the
past
and
I'd
like
to
maybe
make
progress
on
this,
I
believe
that
we
should
split
up
the
current
so
currently
resource
timing.
A
Information
is
all
being
exposed
behind
the
timing.
Allow
origin.
I
believe
that
this
is
not
ideal.
I
think
that
timing
related
information
should
remain
behind
timing.
Allow
origin,
but
also
be
implicitly
provided,
for
course,
enabled
resources,
and
then
there
are
questions
on
whether
we
need
some
sort
of
a
host
level,
opt-in
that
for
the
information
that
it
that
goes
beyond
what
the
resources
expose.
A
A
We're
already
exposing-
or
we
agree
to
expose
as
part
of
the
memory
measurement
api,
the
resource
size,
information
for
cross-origin,
isolated
contexts.
So,
in
that
sense,
resources
that
agreed
to
be
embedded
through
corp
implicitly
agree
to
have
their
sizes
be
exposed
and
cores
again
it
gives
you
direct
access
to
the
bytes.
So
it's
also
fine
to
expose
the
size
in
that
case
and.
A
A
I
believe
that
something
that
we
can
also
say
that
we're
willing
to
expose
with
corp,
especially
because
partitioned
caches,
are
now
a
thing
and
caching
information
becomes
significantly
less
interesting
than
it
used
to
be
from
a
privacy
leak
perspective
and,
finally,
not
finally,
but
there's
also
the
question
of
metadata,
such
as
status
code
and
content
type,
and
I
don't
think
we
necessarily
need
to
make
decisions
on
that
right
now,
because
this
is
not
something
that
we
are
currently
shipping.
A
I
think
it
makes
sense
for
corp
to
also
be
the
opt-in
for
that
case,
but
I
could
be
wrong
or
it
could
make
sense
for
some
metadata,
but
not
other
metadata.
So
maybe
we
can
somehow
split
apart
the
different
types
of
metadata
into
different
categories
and
then
for
parent
frame
reporting.
A
A
And
right
now
we
somewhat
decided
to
put
next
hop
protocol
behind
a
tau
opt-in,
but
that
doesn't
really
make
sense,
because
to
me
the
information
that
next
hop
protocol
exposes
is
a
information.
That's
already
observable
and
b
makes
no
distinction,
so
the
concern
there
is
that
it
exposes
things
about
the
user's
network.
A
A
Observable
it's
observable
by
triggering
more
than
six
requests
and
seeing
how
they
react
on
the
network
when
they're
being
sent
and
when
responses
are
being
received.
A
Network
the
network
characteristics
of
different
protocols,
so
http
1
versus
1.1
versus
2
in
particular,
are
extremely
different
from
one
another
and
it's
very
easy
to
trigger
multiple
requests
for
an
attacker
that
wants
to
acquire
that
information.
It's
very
easy
to
trigger
multiple
requests,
seeing
how
they
behave
in
terms
of
timing
and
then
either
through
resource
timing
or
even
through
you
know,
requests
that
are
cores
enabled
and
we
can
see
when
the
bytes
start
to
trickle
in
and
through
that.
It's
very
easy
to
know.
A
If
you're
dealing
with
an
h1
server
or
an
h2
server,
it
may
get
trickier
with
other
protocol
versions,
so
h3
versus
h2,
maybe
a
bit
more
complex.
I
haven't
given
it
a
ton
of
thought,
but
I
mean.
E
Maybe
it's
a
bit
tangential
point,
but
if
that's
actually
true
and
somehow
we
are
exposing
whether
the
user's
behind
a
firewall,
what
kind
of
firewood
it
is.
So
that
sounds
like
a
pretty
bad
fingerprinting
surface
yeah.
That
sounds
pretty
bad.
But
beyond
that
I
mean
it.
E
It
seems
stretched
to
say
oh,
like
you
can
like,
observe
the
network
characteristics
and
based
on
that,
like
you
can
inform
which
protocols
you
use
sounds
a
bit
of
stretch
to
like
say,
because
therefore,
it's
okay
to
expose
the
protocol,
because
it
I
mean
you
may
not
know
what
kind
of
other
resources
you
could
draw
from
the
origin.
Right,
like
you
said
attacker
could
like
request
multiple
resources
and
observe
what
they
do
but
like
attacker,
first
need
to
know
whatever
the
server
like
it's
loading
from
you
need.
You
have
other
resources.
You
can
load
from.
A
E
A
Inspect
without
ever
talking
about
resource
timing,
just
through
coors
fetch
and
but
but
maybe
we
can
maybe
let's
let's
dive
into
that
later.
Maybe
we
can
start
from
the
top
and
see
if
the
web
of
sec
folks,
like
regarding
timing,
like
the
timing
question
and
having
cores
imply
timing,
allow
origin
what
what
do
you
all
think
about
that?
So
basically,
this
part.
F
Yo,
can
I
have
one
clarification
here
as
well
for
all
of
these
you're
saying
that
if
cores
is
on
the
resource,
it
would
also
imply
like
so
that
applies
for
sizes
and
caching
and
metadata
like
are.
C
A
In
a
way,
I
I
I
don't
know
if
I
would
define
it
as
it
becomes
same
origin,
but
essentially
what
I'm
like
my
reasoning
here
is
that
this
information,
like
quartz,
already
enable
byte
for
byte
exposure
for
all
these
things.
So,
in
a
way,
all
this
information
can
be
polyfilled
for
cores,
enabled
resources
without
resource
timing
ever
being
in
the
loop,
and
therefore
I
think
it's
fine
to
expose
it.
In
those
cases.
C
A
Okay,
maybe
I
haven't
thought
about
it
in
that
sense,
but
so
it
doesn't.
A
The
reason
I'm
I'm
afraid
of
calling
it
that
is,
that
the
credential
handling
for
cores
is
very
different,
and
people
may
get
confused
by
that.
But
yeah.
C
B
So
it
seems
to
me
that,
I'm
sorry
were
you
scared.
I
think
you
were
going
to
talk.
E
Yeah
I
was
going
to
say
I
I
I'm
a
bit
skeptical
assertion
that,
because
the
chorus
allows
resources
to
be
read
in
the
originating
origin
like
a
the
one
that
initiated
the
load,
then
it
you
know
and
then
from
there
to
say
that,
oh,
like
all,
these
things
are
observable.
It's
not
really
right.
I
mean
some
of
the
things
in
that
resource
timing
and
the
size
it's
not
necessarily
observable,
depending
on
resource
type
and
how
it's
loaded.
A
So
let's
talk
about
timings
first,
but
I'm
curious
about
your
yeah,
but
but
from
the
things
that
are
relevant
for
timing,
so
you
know
response
start
and
all
those
points
in
between
that
are
related
to
the
resource
level.
Loading.
Do
you
see
any
problem
there
with
exposing
them?
To
course,.
E
E
What
I'm
saying
is
it's
okay,
if
the
chorus
is
a
brand
new
thing,
we're
adding
and
they're
saying?
Okay,
like
you
know,
this
new
thing
would
also
imply
tau,
but
like
a
course
is
a
thing
that
exists
for
decades,
and
people
have
been
using
that
for
decades
and
it's
problematic
to
say
like
oh
this
thing
we
added
before
by
the
way
would
also
mean
this
new
thing.
E
Right,
like
I
mean
imagine
that,
like
in
a
scenario
where,
like
let's
say
like
you,
had
some
sort
of
event
hundred,
you
know
in
html
and
then
suddenly
it
said.
Oh,
if
you
had
an
event
hundred,
we
also
just
you
immediately
get
the
script.
You
know
as
soon
as
you
post
like
that,
would
be
pretty
problematic
right.
E
A
D
So
I
just
wanted
to
follow
up
on
this
point.
I
was
wondering
if
you
could
talk
about
the
delta
between
what
tao
exposes
right
now
and
what
is
observable
via
course,
because
it
seems
like
this
is
the
sticking
point
right,
because
I
think
hypothetically,
if
we
could
convince
ourselves
that
everything
that
is
gated
behind
tao
is
already
observable
in
qualitatively
a
similar
way.
If
you
set
course,
then
the
legitimate
argue
that
jessica
mentioned
becomes
less
less
bad,
let's
say
at
least.
E
D
My
view
right
because
we're
not
expanding
what
course
lets
you
do
in
a
very
meaningful
way.
So
I'm
wondering
if
we
can
go
through,
maybe
some
of
the
specific
properties
that
that
are
gated
behind
tao
and
talk
about
how
they
could
be
read.
If
a
resource
sets
course.
A
Yeah,
okay,
so
looking
at
resource
timing
at
and
the
different
points
in
time
that
it
enables
we
have
redirect
start
redirect
end
connect
so
domain,
lookup,
start
and
end
connect,
start
connect
and
as
well
as
secure
connection
start,
which
basically
exposes
whether
it's
a
tls
or
not,
and
then
request
start
response
start
so
essentially
without
without
tau
and
without
without
tao.
All
we
have
is
the
start
time
fetch
start
and
response
end.
A
And
the
timing
of
origin
gives
us
opt-in
to
everything
in
between,
and
at
least
so,
if
we're
talking
about.
A
What
does
cores
enable
us
to
observe?
I
believe
that
it
will
enable
us
to
observe
the
so
response
start
for
sure,
but
yeah.
I
I.
E
B
Yeah
I'm,
it
seems
to
me
that
there
are
two
categories
of
data
here.
One
category
has
to
do
with
network
conditions
that
are
outside
the
control
of
the
server,
and
the
other
has
to
do
with
the
work
that
the
server
is
doing.
To
give
you
a
response,
and
I
think
that
cores
will
give
you
all
of
the
stuff
that
the
server
is
doing,
especially
like
all
the
response
work.
So
I
start
sending
you
bits
and
then
you
can
stream
those
bits.
So
you
have
a
good
indication
of
when
they're
actually
landing.
B
B
It
certainly
doesn't
give
you
dns
and
in
fact
it's
weird
that
tau
gives
you
dns,
but
that's
a
separate
conversation
and
it
doesn't
give
you
the
tcp
characteristics,
and
it's
also
weird
that
tao
gives
you
tcp,
but
those
are
network
considerations
that
seem
different
in
kind
from
server
considerations.
B
B
Yeah,
but
I
see
that
as
like
the
the
characteristics
of
how
the
resource
is
delivered
from
the
server
to
you
like
how
the
bits
are
flowing
to
you.
That
seems
like
a
thing
that
coors
has
to
give
you,
because
you
see
all
the
bits
that
seems
different
and
kind
to
me
than
how
long
did
a
dns
look
up
to
some
other
server
that
has
literally
nothing
to
do
with
the
resource.
B
A
So
I
agree
which
is
so.
I
agree
that
those
are
different
types
of
information,
so
so
we
have
the
resource
level
bits,
the
origin,
level
bits
and
the
user
network
level
bits.
So
I
agree
that
dns
is
a
different
story
and.
B
Doesn't
I
mean
I'm
honestly
like
me
personally,
I
am
less
concerned
about
the
origin
level
characteristics
than
I
am
about.
The
network
level
characteristics
simply
because
it's
not
clear
to
me
that
the
current
setup
actually
gives
anything
like
a
reasonable
opt-in
for
the
network
level
characteristics
the
server
level
characteristics.
I'm.
I
can
be
comfortable
saying
that
by
exposing
a
resource
via
cores,
you
give
information
about
the
way
that
a
connection
was
made
to
the
server
like
I
can.
I
can
kind
of
justify
that
to
myself
the
dns
and
tcp.
B
Well,
the
dns
level
data
seems
quite
different
and
kind
to
me
and
it
it
doesn't
appear
to
me
that
cores
would
normally
let
you
see
that
data.
Nor
does
it
seem
to
me
that
it
should,
since
it's
a
completely
different
server
whose
characteristics
you're
revealing.
B
I
think
that's
also
true,
of
next
top
protocol,
insofar
as
that
has
that
is
somebody
else's
data
that
I
am
saying
that
you
have
access
to,
but
I
have
no
control
over
that
and
it's
not
mine
to
reveal.
C
So
one
other
question
I
had
so,
if
we're
thinking
about
this
about
those
opt-ins
being
complicated,
if
tao
only
gives
you
timings
and
it's
called
timing,
origin-
and
this
is
the
thing
you
obtain
to
have
timings,
and
if
you
don't
have
it,
you
don't
have
the
timings
that
seems
to
me
like
a
simple
enough
mental
model
to
have
which
is
if
I
want
the
timings.
I
have
this
thing
and
if
I
don't
have
this
thing,
I
don't
have
the
timings
versus
having
some
implications
for
parts
of
towel.
A
So
the
motivation,
at
least
from
my
perspective
here,
is
that
after
I
don't
know
how
many
years
we
still
have
low
adoption
of
tau
even
for
resources
that
are
static
in
public
and
no
one
really
cares
about
their
timing
and
introducing
cores
to
the
equation
for
the
bits
of
information
that
are
already
exposed
through
cores
would
significantly
increase
the
visibility
we
have
in
web
performance
for
what
third
parties
are
doing
and
at
least
the
way
I
was
imagining
it
without
compromising
any
of
the
security
bits.
B
A
Yeah
so
going
back
to
the
splitting
of
the
top
like,
so
from
your
perspective,
it
would
be
fine
for
the
resource
level
timings,
but
not
for
the
origin
level
and
definitely
not
for
the
user
network
level.
B
A
Okay,
so
moving
to
sizes
right
now,
sizes
are
exposed
with
timing,
allow
origin,
and
what
I'm
proposing
is
that
we
would
stop,
and
that
would
hopefully
enable
browsers
that
haven't
implemented
the
sizing
related
bits
of
resource
timing
to
potentially
implement
them,
and
we
would
move
away
from
a
tau
based
opt-in
to
a
I
don't
know
if
corp
based
opt-in
is
the
right
term
or
a
cross-origin
isolated
context.
So
I
don't
know
if
a
corp
opt-in
on
its
own
would
give
you.
A
This
size
for
any
random
attacker
and
that
that
point,
maybe.
B
I
in,
in
my
mind,
the
the
reason
that
corp
is
used
for
cross-origin
isolation
and
not
cores
is
that
we
wanted
to
create
a
distinction
between
granting
access
to
read
all
the
bits
and
know
the
content
of
a
thing
from
the
ability
of
using
that
thing
as
part
of
your
website.
So
we
wanted
to
create
a
mechanism
by
which
you
could
embed
something.
Opaquely
have
the
ability
to
transclude
it
in
your
page,
but
not
have
the
ability
to
understand
what
it
is.
B
So
things
like
side
effects
from
a
500
or
404
error,
which
would
be
directly
exposed
via
the
metadata
as
a
mechanism
of
determining
whether
a
particular
resource
was
for
a
logged
in
user
or
non-logged-in
user
or
whether
they
had
access
to
a
particular
thing
or
a
variety
of
other
things
that
you
could
learn
by
examining
what
a
particular
user
has
access
to.
So
I'm
I'm
a
little
bit
worried
about
blurring
the
line
between
including
a
resource
and
reading
the
resource.
B
I'm
not
convinced
that
that's
a
line
that
we
can
actually
hold.
So
I'm
totally
willing
to
debate
this
a
bit.
But
if
that
is
a
line
that
we
can
hold,
then
it
seems
pretty
clear
to
me
that
corp
can't
give
you
size
and
that
corp
can't
give
you
metadata
that,
in
fact
all
corp
can
do
is
give
you
access
to
pull
in
a
resource
and
you're
right
to
say
that
for
size
in
particular,
we
might
already
be
over
that
line
with
the
memory
measurement
work.
B
That's
I
saw
oolan
on
the
call
earlier,
so
I
assume
he's
around
somewhere
is
working
through
in
chromium,
so
this
this
might
already
be
a
line
that
that
is
is
untenable.
But
I
guess
I'm
curious
as
to
what
your
thoughts
are
about
that
framing
and
whether
it's
one
that
makes
any
sense.
A
So
the
reason
why
I
thought
it's
okay
is
exactly
because
of
memory
measurement
and
because
that
is
already
something
that
is
exposing
those
sizes
another.
So
the
js
profiling
is
another
bit
that
goes
beyond
just
the
embeddability
of
the
resource
and
enables
profiling
of
javascript
resources,
which
seemed
also
something
that
goes
beyond
just
you
know.
It
doesn't
give
you
the
by
byte
characteristics
of
the
of
the
resource,
but
it
does
provide
some
information
about
it.
B
I
I
it's
entirely
possible
that
I've
misunderstood
the
scope
of
those
apis.
My
understanding
was
that
those
were
only
related
to
the
amount
of
memory
that
was
taken
up
by
javascript
and
javascript
objects.
Is
it
also,
including
all
of
the
memory
that's
associated
with
things
like
images
that
are
loaded
onto
the
page
and
other
sub-resources
like
fonts,.
G
So
the
icon
answer
that
for
measuring
memory.
Initially
it
was
about
javascript,
but
since
after
having
the
cross
region
isolation
mechanism,
we
saw
that
we
can
expand
it
to
more
memory.
B
C
It's,
however,
it's
pretty
clear
that
none
of
that
gives
you
the
metadata,
for
example,.
D
So
can
I
chime
in
because
I
actually
think
the
the
answer
to
what
mike
mentioned
like
there
are
two
parts
of
the
answer.
Right.
One
is
the
explicit
apis
like
performance
measure
memory,
and
the
second
part
of
the
answer
is
the
fact
that
by
setting
corp,
you
are
agreeing
to
having
the
resource
being
loaded
into
the
address
space
of
another
cross-origin
renderer,
which
allows
you
know.
D
We
can
probably
argue
about
whether
that
is
the
web
threat
model
or
not,
but
in
practice
it
allows
you
to
put
the
resource
in
cross-origin
under
earth's
admin
space,
which
means
that
the
renderer
can
read.
The
specific
bytes
can
be
the
size
of
the
resource,
the
specific
bytes
of
that
resource
and
the
metadata
included
in
that
resource.
B
So
I
think
that
the
the
the
way
that
I
was
thinking
about
this
a
year
ago
was
make
the
attacker
do
the
attack.
That
is,
it
is
the
case
that,
by
allowing
your
resource
to
be
included
into
someone
else's
address
space,
there
is
risk
that
a
malicious
entity
could
try
to
gain
more
information
than
should
be
available.
Based
on
the
api
surface
that
we
expose
cores
grants
that
access-
that
is,
it's
an
explicit
mechanism
to
give
the
the
other
party
access
to
all
of
that
information.
B
B
B
C
Sure
I
mean
after
we
can
argue
about
how
easy
the
attack
is
in
particular
for
size.
If
you
can
just
read
the
memory
measurement
api.
That
seems
a
very
obvious
attack,
that's
very
quick
to
do
and
I'm
not
sure,
there's
that
much
value
of
hiding
it
compared
to
having
them
perform.
It.
B
Yeah,
I
guess
I
I.
I
am
a
bit
surprised
that
the
memory
measurement
api
reveals
information
beyond
the
state
of
the
javascript
heap
and
I
need
to
think
about
that.
E
I
I
have
to
say,
though
yesterday
that
was
exactly
the
point
I
raised,
which
is
that
we,
I
have
a
serious
concern
about
that
aspect
of
memory
measurement
api
and
we
have
already
said
that
we're
not
going
to
implement
the
js
profiling
api
so
both
of
those
points
people
are
making
so
far
as
to
why
those
information
is
exposed
is
completely
invalid.
In
our
view,.
A
Yeah,
so
the
problem
or
I
have
so
in
my
view.
A
B
Yeah,
that
was
the
the
next
slide
in
your
presentation,
yeah
it
I
I
do
wonder-
I'm
not
convinced
of
this
yet
but
I'll,
throw
it
out
there
and
y'all
can
tell
me
that
it's
crazy.
It
might
be
the
case
that
it
would
be
valuable
for
servers
to
have
some
sort
of
explicit
signal
that
a
resource
is
not
in
any
way
influenced
by
the
user.
That
is
requesting
it
that
it
is
not
a
personalized
resource
that
instead,
it
is
a
resource
that
is
static.
B
I
think
there's
a
lot
of
room
for
like
for
discussion
about
what
those
things
might
be,
but
it
seems
to
me
that
creating
a
mechanism
for
the
server
to
make
this
kind
of
assertion
and
also
a
mechanism
for
the
browser
or
for
the
site,
rather
to
make
an
assertion
that
it
expects
the
resources
that
it
requests
to
have
this
kind
of
characteristic
might
give
us
some
freedom.
I
see
ian
just
popped
up,
and
I
know
that
he's
thought
about
this
in
the
past.
B
With
regard
to
a
credentialless
request
mode,
I
don't
know
where
the
document
actually
lives,
but
maybe
there's
something
that
you
could
point
to
again.
H
B
Things
so
I
mean
I,
I
think,
that's
a,
I
think,
that's
a
good
idea,
apart
from
whether
it
gives
us
any
more
ability
with
regard
to
the
timing,
proposals
and
opt-ins
that
we're
talking
about
here
but
b,
I'm
wondering
that
I'm
wondering
whether
there
is
a
specific
category
of
resource
that
the
folks
in
this
group
are
really
interested
in
getting
data
about,
and
whether
that
category
includes
mostly
this
kind
of
content
where
I'm
trying
to
load
something
from
a
server
where
the
thing
that
I'm
trying
to
load
isn't
at
all
related
to
the
user.
B
It's
just
like
a
resource
that
I
need
for
my
page
to
load
and
it's
going
to
be
the
same
resource
for
everyone
it.
I
wonder
whether
there
are
things
that
we
could
do
with
caching.
I
wonder
whether
there
are
things
that
we
could
do
at
various
levels
of
the
stack.
If
we
had
an
assertion
that
this
particular
resource
is
never
personalized,
and
that
might
give
us
some
freedom
with
regard
to
sizes
and
with
regards
to
metadata,
because
if
it's
not
a
personalized
resource,
then
obviously
the
size
is
going
to
be
the
same
for
everyone.
B
Now,
of
course,
you
need
to
think
about
how
servers
would
try
to
abuse
this
and
whether
there's
some
messaging
potential
that
this
would
expose.
But
it
seems
to
me
that
the
idea
is
worth
exploring
and
might
create
a
subset
of
resources
for
which
we
can
have
a
different
set
of
rules
than
resources
in
the
main.
A
Yeah
so
I'll,
let
the
analytics
folks,
maybe
answer
your
question.
It's
just.
I
wanna
small
comment.
Just
it's
unclear
to
me
what
the
delta
from
a
developer
perspective.
What
would
be
the
delta
between
this
and
corp
uses.
D
No,
please,
I
think
you
may
answer
my
question
as
well.
If
you
keep
talking
mike.
C
B
B
That
is,
if
you
get
cookies,
along
with
a
course
request,
you
have
to
send
an
acio
header
back
and
there's
another
kind
of
resource
that
is
readable
across
origin,
but
is
not
user
specific
and
we
currently,
we
currently
have
that
in
cores
with
acio
star,
but
we
get
lots
of
feedback
from
lots
of
people
that
that's
really
hard
to
use,
because
you
have
to
know
that
you
have
to
request
it
in
anonymous
mode
and
like
retries
and
all
the
stuff
and
that
if
we
reset
expectations
instead
of
around
cores
as
being
like,
this
is
a
totally
public
resource
and
is
requestable
in
in
a
public
way.
B
And
I
don't
care.
If
I
get
cookies,
you
can
send
cookies.
You
cannot
send
cookies,
doesn't
matter,
I'm
public,
but
that
is
a
different
category
of
resource
different
in
kind
from
things
that
use
cores
and
also
different
in
kind
from
things
that
use
corp.
Assuming
that
you
accept
this
distinction
between
readable
and
not
readable,.
A
So
in
my
slide
here
I
think
you
can
replace
corp
with
that
magical
mode
if
we
had
that
like
if
we
had
that
magical
mode
today,
this
is
what
I
would
put
there.
It's
just
that
yeah.
It's
unclear
to
me
that,
like
what
the
difference
is,
but
maybe
we
could
let
the
analytics
folks
provide
more
like
more
details
on
the
type
of
resources
they're
interested
in
getting
more
information
on.
A
So
I
know
maybe.
F
F
And
if
not,
I
will
just
talk
about
some
of
our
needs
for
for
rum
analytics,
so
things
like
sizes
is
important
to
us
from
just
a
kind
of
like
a
page
weight
point
of
view.
So
today
we
we're
reporting
resource
sizes
for
all
of
the
content
on
our
customers
pages.
F
We
know
that
it
is
not
complete
because
of
because
of
all
these
things,
and
so
if
our
customers
were
able
to
really
truly
track
something
closer
to
the
actual
page
weight,
especially
with
third-party
resources,
they
would
have
a
better
sense
of
what
the
actual
cost
of
those
are
of,
including
those
widgets
and
ads,
and
all
these
kind
of
kinds
of
things
versus
really
only
getting
it
for
their
first
party,
con
first
party
or
tao,
enabled
content
today.
F
That's
what
so,
that's
one
particular
thing.
You
know
from
a
cdn
point
of
view.
We
can
also
use
some
of
this
data
to
help
improve
our
network,
make
sure
things
are
going
smoothly
from
both
the
sizes
and
caching
point
of
information
that
we
could
get
but
yeah
a
lot
of
it.
Just
basically
comes
down
to
page
weight
and
being
able
to
more
accurately
actually
know.
What's
going
on
the
page
at
its
cost,.
F
And
certainly
things
like
the
other
metadata
like
and
we
haven't,
talked
about
status,
codes
and
content
type,
but
all
of
that
can
help
us
spot
problems.
Spot
inefficiencies
help
make
our
customer
sites
faster
for
their
visitors
et.
F
A
Yeah,
I'm
on
youtube
from
a
resource
type
perspective.
Do
you
have
any
visibility
into
whether
most
of
those
third
parties
that
you
want
to
track?
Are
they
credentialed?
Are
they
user
specific?
Is
it
something
that
the
third
party
origins
can
safely
say?
This
is
public,
don't
worry
about
it.
F
A
But
I
don't
believe
it
was
around
like
25
tile
and
then
25
more
with
cores
right
yep,
something
around
there
something
around
those
orders
of
magnitude.
A
So
so
I
think
that
the
like,
from
a
developer
perspective,
the
difficulty
about
cores
is
a
pre-flights
and
b
the
fact
that
you
can't
really
opt
in
all
your
resources
to
coors,
and
even
if
you
like,
for
the
cases
where
you
can,
you
have
to
explicitly
say
on
each
one
of
them.
This
is
cross-origin,
like
you
have
to
add
the
cross-origin
attribute,
which
is
not
intuitive
and
no
one
really
gets
it.
So
it's.
A
I
I
see
the
appeal
in
yeah
in
that
kind
of
like
that
resource
is
not
at
all
credentialed,
nor
you
know
not
user
specific
kind
of
header
from.
B
Even
if
it
overlaps
with
cores
yeah,
maybe
it's
some
context.
The
the
place
I
would
like
us
to
get
is
a
place
in
which
the
defaults
are
different
than
they
are
today.
B
That
is,
I
think
it
would
be
good
for
us
to
move
to
a
credentialist
request
mode
by
default
and
to
opt
in
specific
requests
to
contain
credentials
and
that
opt-in
might
be
coors.
It
might
be
spelled
in
the
way
that
I
was
just
talking
about
as
like
public
public
or
personalized
resource
or
something
along
those
lines.
B
And
like
that
comes
in
two
steps,
the
first
step
is
to
introduce
a
new
cross-origin
and
better
policy
right
now
we
have
require
corp.
We
should
add
something
to
that.
That's
like
don't
send
my
credentials
spell
it.
However,
you
like,
and
we
would
need
to
introduce
we
wouldn't.
We
could
then
introduce
something
on
the
server
side.
I
E
D
A
cross-origin
page
to
to
load
my
resource
and
potentially
leak
its
contents.
If
it's
cross-origin
isolated
as
opposed
to
what
you
are
talking
about,
which
is,
and
let's
say,
attaching
a
label
to
the
resource
saying
it
is
unauthenticated.
But
I
don't.
E
D
Why
corp
cross-origin
is
not
a
super
set
of
what
you
are
talking
about,
that
you
would
be
comfortable.
You
know
treating
as
such
right
so
so
to
me.
Cross-Origin
encompasses.
B
B
That
might
well
be
the
case.
I'm
I'm
totally
willing
to
be
convinced
that
this
distinction
is
completely
illusory
or
that
it
is,
in
fact
a
superset.
B
It's
certainly
not
the
way
that
I
was
thinking
about
corp
versus
cores
when
we
originally
designed
cross-origin
and
better
policy.
That
said,
I'm
I'm
very
willing
to
be
convinced
that
this
that
this
distinction
is
not
one
that
makes
any
difference
and
that
it's
it's
not
worth
trying
to
introduce
complexity
around
these
concepts.
B
It
seems
to
me
that,
in
the
status
quo,
there
are
resources
that
do
want
to
change
their
content
based
on
the
user,
but
that
do
not
intend
for
that
content
to
be
accessible
to
the
context
in
which
they're
embedded
that
might
not
be
possible,
and
we
might
just
have
to
to
say
that,
because
it's
not
possible
because
computers
are
broken,
that
we
have
to
align
the
api
surface
of
the
web.
To
that
reality.
B
That
might
well
be
reasonable.
I
don't
think
I'm
quite
yet
willing
to
give
that
up.
It
seems
to
me
that
there
is
a
line
there
that
we
can
hold.
It
might
be
such
a
thin
line
that
it's
not
worth
trying
to
draw.
I'm
not
yet
convinced
of
that.
A
What
concerns
me
about
drawing
that
line
is
that
people
will
trip
over
that
line
and
fall
and
break
their
face
and,
in
my
view,
it's
better
to
have
a
clear
line
that
splits
you
know
personalized
from
non-personalized,
then
various,
I
guess
criminalization
on
the
way,
but.
B
B
If
it's
the
case
that
for
all
of
those
resources,
we
would
also
be
comfortable
using
cores
and
exposing
them
cross-origin.
That
is
without
any
particular
restriction
on
the
origin
that
is
actually
able
to
read
the
data.
Then
that's
a
strong
argument
in
favor
of
that
distinction,
not
being
one
with
a
difference.
D
D
If
we
were
to
set
core
cross-origin
on
a
resource
that
has
authenticated
information,
we
would
treat
this
as
a
vulnerability
right,
because
part
of
the
cross-origin,
isolated,
cross-origin,
opener
policy
and
better
policy
model
is
that
this
resource
may
end
up
in
another
space
of
someone.
So
one.
B
B
Like
I'm,
I'm
juggling
a
lot
here,
but
let's
assert
that
browsers
have
not
yet
all
gotten
to
a
point
where
out
of
process.
Iframes
are
consistently
a
thing
in
that
world.
I
think
there
are
html
documents
that
would
not
want
to
be
legible
to
there
and
better
and
yet
want
to
be
embedded
and
if
we
I
I
feel
like
that,
has
to
be
a
line
that
we
hold.
B
C
B
Give
my
kids
some
dinner,
so
what
is
the
the
right
place
to
continue
this
conversation.
A
That
is
a
good
question.
I
think
we
can
kick
off
an
issue
on
resource
timing.
Maybe
summarize
the
this
discussion
and
I'll
do
my
best
to
do
that
and
yeah,
and
then
we
can
continue
that
conversation.
There.
E
Yeah,
so
by
the
way
I
wanted
to
echo
the
point
mike
just
made,
which
is
that
I
think
we
have
to
hold
the
line
that,
like
there
are
resources
that
it
wants
to
be
embedded
to
embed
it,
but
wouldn't
be
willing
to
have
its
content
read.
In
fact,
we
have
devised
some
plans
to
do
that
in
a
case
where
the
processization
is
in
place.
We
we
have
actually
thought
about
many
resource
types.
E
I
think
the
hardest
one
is
the
scripts,
but
just
because
it
gets
executed
in
in
there,
but
there
are
like,
for
example,
things
like
images.
There
are
no
reason
why
it's
content
and
method
that
needs
to
be
other
than
that.
Let's
say
size
needs
to
be
readable,
legible
by
the
content.
That
loaded
with
the
course
right.
So
a
quote
brother.
So
so
I
think
there
there's
a
lot
of
things
that,
like
a
lot
of
assumptions
being
made
here
that
are
not
necessarily
agreed
upon
by
all
the
browser
vendors
either.
A
One:
okay,
cool
okay.
So
with
that
yeah,
we
will
continue
that
conversation
over
github
artur.
You
had
your
hand
raised.
I
don't
know
if
it's
yeah.
A
Okay,
so
with
that,
I
think
we
can
move
on
to
reporting
api
updates.
Let
me
unshare
my
screen
so
that
ian
can
share
these
that'll.
Try
to
share
mine.
H
H
Okay,
so
let's
see
in
the
agenda,
this
was
called
reporting,
api
updates
and
you
can
see
the
slide
is
reporting
your
network
reporting
apis.
H
But
first
I
guess
a
couple
of
implementation
and
usage
updates.
So
I
believe
that
currently
chrome
is
the
only
one
implementing
this
I'd
love
to
hear.
If
I'm
wrong
about
that,
we
have
support
for,
of
course,
csp
reports,
network
error,
logging.
H
We
have
deprecation
intervention
and
crash
reports,
we
have
just
started-
or
maybe
just
on
the
tail
end
of
a
origin
trial
for
reporting,
co-op
and
co-op
violations,
and
we
have
support
behind
a
flag
that
hasn't
actually
shipped
yet
for
reporting
violations
of
permission
and
document
policies.
H
In
the
real
world,
chrome
sees
the
javascript
reporting
observer
api
used
on
about
four
percent
of
all
page
views,
and
I
couldn't
find
any
sort
of
metrics
inside
chrome
about
the
actual
report
to
header.
So
I
did
a
quick
scan
of
http
archive
data
and
it
looks
like
about
point
five
percent
of
the
top
five
million,
or
so
home
pages
actually
set
a
report
to
header
and
they're
using
the
reporting
api
that
way
so
updates
since
this
time
last
year,
so
yeah.
H
H
Previously,
these
were
all
part
of
the
reporting
api
which
led
to
some
concern
about
whether
or
not
they
were
actually
going
to
be
required.
So
those
are
all
in
incubation
and
should
be
the
source
of
lots
of
discussions,
interesting
things
to
talk
about
there,
so
the
reporting
api
itself
has
been
stripped
down.
H
H
That
spec
defines
the
concept
of
what
a
reporting
endpoint
is,
and
you
know
where
votes
in
the
document
or
worker
that's
actually
held,
and
then
it
defines
what
we're
calling
document-centered
reporting.
So
document-centered
reporting
is
reports
which
are
tied
to
the
lifetime
of
a
single
document
and
are
not
mixed
with
reports
from
other
documents.
H
The
reporting
api
defines
how
to
configure
that
and
how
to
use
the
javascript
reporting
observer
api
to
actually
observe
those
things
in
real
time.
In
your
page,.
H
So
document
centered
actually
includes
workers
as
well.
I've
just
recently
merged
the
pr
to
add
support
for
workers,
I
think
previously
they
were
being
reported
through
their
creator
document.
If
you
had
a
dedicated
worker-
and
I
don't
think
we
supported
reporting
at
all
in
shared
workers
or
service
workers,.
H
H
H
There
was
a
fair
bit
of
discussion
about
that
at
tpac
last
year
and
was
sort
of
ongoing
for
a
while,
eventually
decided
that
same
origin
credentials
are
probably
okay
and
can
be
quite
useful
at
times
and
cross-origin
credentials.
We
should
get
rid
of.
So
that's
what
we've
done.
H
H
Itself
now
contrast
this
with
the
network
reporting
api.
So
all
of
the
bits
of
the
reporting
api
that
existed
to
support
things
like
network
error,
logging
specifically
have
been
removed
and
placed
in
this
spec.
So
this
extends
reporting
and
the
purpose
of
it
is
to
handle
these
cases
like
network
error
logging,
where
the
reporting
is
necessarily
out
of
band,
it
can't
be
tied
to
a
specific
document,
either
can't
or
shouldn't
and
needs
to
be
sent
seems
to
be.
You
know,
queued
up
and
sent
outside
of
the
scope
of
any
particular
document.
H
We
also
in
that
extend
the
concept
of
endpoints
to
endpoint
groups,
network
error
logging,
specifically
because
it's
reporting
on
network
conditions-
and
you
know
your
preferred
endpoint-
may
not
be
available.
We
have
the
concept
of
a
group
where
you
can
add
multiple
endpoints
and
give
them
priorities
and
weights.
H
So
you
could
have
cases
where
a
misconfigured
server,
one
response
might
overwrite
the
configuration
of
another
response.
You
couldn't
necessarily
set
up
different
reporting,
endpoints
per
document
and
generally
conflating
these
things.
So
what
we've
done
is
we've
said.
Okay,
network
reporting
is
an
origin
level
concern.
Essentially
it
was
always
defined
as
such,
and
so
we
want
to
use
a
mechanism
like
origin
policy.
Currently,
that's
what
spect
origin
policy
hasn't
shipped,
but
that's
a
sign
issue.
H
J
H
And
then
yeah,
so
we
still
have
some
issues.
These
aren't
quite
polished,
yet
the
reporting
document
reporting
needs
to
integrate
with
html
that
pr
is
open
but
hasn't,
landed
and
probably
needs
some
more
updates.
So
before
we
do
that,
there's
questions
about
which
task
key
we
want
to
use.
There
are
spec
level
questions
about
report
types
being
defined
as
idl,
which
the
web
platform
web
platform
test.
People
don't
like
very
much
because
it
makes
us
generate
lots
of
tests
for
objects
that
we
don't
really
need.
H
Whether
or
not
the
reporting
mechanism
entirely
should
be
a
user
opt-in
thing,
whether
users
should
have
control
over
what
types
of
reports
are
sent
out
or
whether
I
think
in
the
extreme.
You
know
every
report
should
bring
up
a
dialogue
saying.
Would
you
like
to
report
this
to
the
to
the
site,
and
I
don't
think
we've
achieved
any
sort
of
resolution
on
that.
H
A
Cool,
thank
you
so
just
as
a
reminder,
since
the
you
know
10
years
ago,
that
happened
since
fukuoka.
A
The
reasoning
for
splitting
up
the
previous
reporting
api
into
two
separate
infrastructure
is
that
I
believe
mozilla
was
interested
in
implementing
one,
but
not
the
other.
The
document
scoped
one
is
that,
do
I
remember
correctly.
H
I
can't
speak
for
mozilla
and
I
don't
know
if
there's
anyone
representing
them
on
the
call,
but
that
roughly
matches
my
recollection
that
they
were
interested
in
reporting
for
co-op
and
co-app,
but
the
spec
as
it
was
written
and
implemented.
Yeah
had
some
issues
that
we
wanted
to
resolve.
First,
specifically
around
bundling
of
reports
from
different
documents
together.
A
A
Thanks
yeah
on
the
origin
policy
front
that
you
mentioned.
A
A
Is
there
any
movement
on
that
front,
because
I
know
last
time
I
looked,
there
were
a
bunch
of
open
issues
there
with
regard
to,
for
example,
the
performance
implications
of
origin
policy
related
things,
making
it
in
time
to
impact
the
document,
but
from
a
network
reporting
perspective.
Maybe
that
is
not
as
awful
as
for
other
use
cases.
H
H
Origin
policy
seemed
like
the
best
candidate
for
that
it
may
not
be
the
only
one.
A
H
H
G
G
So
I
guess
I
guess
benjamin's
not
here
so
I'm
coming
from
mozilla
but
I'm
not
too
sure
actually
so.
K
J
J
I
I
don't
have
any
strong
feelings
about
it,
but
I
can't
say
I
followed
it
closely
enough
to
have
noticed
any
details.
I
may
disagree
with
so
unfortunately,
that's
not
a
very
useful
comment.
H
For
the
the
privacy
issues
themselves,
is
this
something
that
this
group
should
take
to
the
private
ccg
and
try
to
poke
the
discussion
there?
A
Normally
we
just
tackle
issues
until
we
think
that
they're,
you
know
they
have
a
good
privacy
story.
We
can
definitely
trying
to
involve
more
privacy,
oriented
folks
in
those
discussions
and
make
sure
that
we
take
everything
into
account,
so
not
necessarily
take
it
to
the
privacy
cg,
but
maybe
bring
in
folks
from
the
privacy
cg
to
review
the
bits
and
pieces
that
we
think
need
review.
A
Yeah
and
and
yeah
so
the
wide
review
privacy
phase
is,
I
think,
somewhat
later,
but
maybe
we
could
kick
off
that
particular
part
and
and
that's
ping
right.
I
I
A
Boolean
and
the
user
control,
one
like
it
seems
like
we
don't
want
reports
to
be
able
to
maintain
state
beyond
what
cookies
can
today
and
as
such,
we
can,
you
know
the
answer
is:
either
they
do
or
they
don't,
and
if
they
do,
we
should
fix
it.
A
A
more
opinionated
one
rather
than
like,
and
there
are
various
right
answers
there,
depending
on
your
opinion
and
the
user's
opinion.
I
guess
right.
H
So
it's
honestly
something
that
I
would
prefer
to
leave
up
to
the
implementers.
You
know-
and
I
think
that
there's
space
for
you
know
browsers
to
have
different
opinions
about
these
things.
A
H
I
agree
with
everything
you
said
as
far
as
capability
urls
go.
I
think
that
the
the
thing
to
do
is
to
figure
out
the
wording
very
carefully,
because
there's
nothing
there's
nothing.
The
browser
can
do
to
prevent
capability
urls
from
leaking.
It
has
to
be
on
the
site's
owner
to
not
include
those
in
reports
and
understand
where,
in
their
site,
those
are
and
ensure
that
they
don't
get
out
across
origin.
A
A
Yeah
and
and
the
risk
there
so
is
there-
is
there
tracking
through
reports
or
is
the
risk
something.
J
H
H
A
A
H
Interesting
so
providing
both
a
limited
url
and
the
hash,
the
concern
being
that
the
first
party
can't
necessarily
trace
back
a
report
to
the
right
to
the
page
that
generated
it.
If
that's
important,
yeah
so.
A
They
could,
but
they
will
have
to
keep
like
the
hash
to
url
mapping
right
that
enables
them
to
do
that.
I
so
I
don't
know
if
it
makes
sense,
but
okay,
it's
worth
proposing.
I
I.
J
H
A
Yeah
makes
sense
yeah,
otherwise
I
think
we're
on
our
time
for
a
break.
So
unless.
A
We
can
wrap
that
up
and
then
get
back
in
15
minutes
to
talk
about
how
reporting
api
can
be
relying
on
to
maybe
report
performance,
metrics
cool,
so
yeah
see
you
all
in.