►
From YouTube: WebPerfWG call - Feb 13 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
Okay
and
finally,
on
the
administrative
side,
I
sent
an
email
today
where
we
were
basically
in
search
of
another
co-chair
to
you
know
to
help
manage
the
group.
So
if
anyone
here
is
interested
other
than
Nick,
that's
already
replied
gracefully,
we
let
us
know
either
publicly
or
privately
and
yeah.
Well,.
A
Okay
and
now
for
actual
discussion,
we
have
a
few
proposals
here.
We
want
to
discuss
today
and
then
a
bunch
of
issues.
Most
of
them
are
related
to
resource
timing
in
the
resource
timing,
performance
API
in
general,
and
privacy
and
security
related
concerns.
But
let's
start
off
by
talking
a
bit
again
about
this
impending
Andrew.
C
Cool,
so
this
is
gonna,
be
pretty
brief.
I
just
thought:
I'd
clarify
a
few
things
from
some
prior
calls
and
bring
up
some
topics
for
discussion
that
thought.
Maybe
he
should
be
fleshed
out
a
little
bit
more.
We
might
have
talked
about
briefly
at
CPAC,
particularly
regarding
the
need
to
yield
without
missing
the
pennant,
let's
dive
into
it
so
yeah.
C
Last
time
we
talked
about
the
issue
of
like
correct
frame,
attribution
off
the
main
thread
with
iframes,
and
particularly
the
tricky
case
of
iframe
motion
where
you
might
there's
I've
talked
about
this
a
million
times
by
now,
but
you
click
like
in
a
region
where
an
iframe
is
not
say.
The
iframe
use
interview
user
agent
has
to
take
very
careful
like
procedure
to
ensure
that
the
parent
can't
detect
isn't
appending
when
the
Dom
event
gets
dispatched
to
the
iframe,
wins
cross
origin,
of
course,
and
so
chat
a
little
bit
about
that.
C
How
a
locking
based
solution
that
fixes
Dom
events
to
the
origin
that
could
be
detected
as
the
owner
of
that
event
off
being
thread
would
be
potentially
a
good
solution
and
we're
gonna
tag
review
as
well.
We
also
chat
a
little
bit
about
moving
to
the
whole
like
by
part,
a
continuous
discrete
like
this
map
ending
option.
Struct
have
beaten.
We
believe
that
quite
handles
the
large
majority
of
events
that
users
want
to
listen
for
so
diving
straight
back
into
it.
C
I
want
to
make
it
clear
that
the
current
chrony
augmentation
does
not
suffer
from
the
Dom
events.
Different
problem,
I
didn't
make
this
terribly
clear,
and
it's
primarily
because
I
was
trying
to
focus
on
the
issue
that
main
threat
event.
Attribution
would
be
insufficient
for
delegating
this
completely.
So,
with
the
existing
loop
with
infrastructure,
we
effectively
ensure
that
once
a
frame
or
what's
an
input,
event
is
dispatcher
even
render
a
process.
It
cannot
jump
around.
So
the
frame
that
can
detect
is
impending
true
will
be
the
only
frame
that
receives
the
Dom
fat.
C
That
being
said,
I
was
a
little
bit
worried
about
whether
or
not
the
intent
to
dispatch
an
event
which
is
where
say
a
renderer
receives
the
ISM
impending
bit
off
me
and
thread
that
in
event
is
intended
for
an
origin,
and
then
later
frame
motion
causes
the
event
not
to
be
dispatched.
Could
leak
the
sort
of
intent
from
the
user
that
they
wanted
to
click
inside
of
an
iframe
that's
cross
origin,
even
though
it
was
not
resulting
in
a
dominant
dispatch.
C
So,
like
suppose,
the
main
thread
is
blocked
and
you
click
on
a
region,
and
then
that
gets
attributed
to
a
given
process
and
then
that
process
decides
oh,
it's
like
this
wasn't
actually
dead.
For
me,
that
was
like
an
iframe
here
by
the
time.
The
event
is
actually
like
queued
for
dispatch
on
the
main
thread,
and
so
in
that
case,
if
that
origin
was
like
pulling
his
map
ending
and
they
notice
that
they
didn't
get
the
event
dispatch,
they
could
infer
that
an
input
was
intended
for
an
extra.
E
C
E
I,
don't
think
what
event
gets
dispatched
or
not
like
makes
a
difference
right
if
you
can
detect
the
presence
of
event.
That
may
or
may
not
eventually
be
this,
because
the
thing
is
page
may
navigate
between
the
time
you
have
detected
that
there
was
a
pending,
Ben
and
event
actually
gets
this
patch.
So
I,
don't
think
I,
don't
think
that's
read
about
at
all!
Well,.
C
How
would
the
event
get
like
this
is
in
the
context
of
the
locking
solution
will
be
discussed
before
where,
based
on
the
current,
like
visual
representation,
we
obtained
the
origin
where
the
event
was
in
1054
and
then,
when
it
comes
time
to
like
queue,
the
test
to
dispatch
that
on
the
main
thread,
we
can
very
obviously
throw
it
away
when
we
notice
that
this
wasn't
where
we
intended
the
event
to
go.
I.
E
E
C
E
C
No,
this
is
in
a
world
assuming
that
we
perform
the
origin,
attribution
off
main
thread.
So
we
know
what
origin
based
on
like
the
last
presented.
State
should
be
associated
with
an
event,
and
what
I'm
suggesting
right
now
is
that
there
is
a
spike,
the
only
sort
of
leak
you
could
call.
It
is
when
you
click
on
a
region
or
say
like
have
an
event
in
a
region,
and
that
is
attributed
to
like
an
origin
and
then
say
the
like
origin
of
that
position
or
the
like.
C
E
E
D
Think
so
you
have
the
currently
presented
stuff
on
the
screen.
We
we
can
do
a
fast
hit
test
to
determine
which
origin
would
receive
the
hit
test
event
if
nothing
changed,
but
then,
when
we
actually
do
the
dispatch
on
when
it
when
the
event
comes
up
on
the
event
loop
to
actually
do
the
dispatch,
we
we
do
a
hit
test
and-
and
the
Dom
may
have
been
mutated
in
the
meantime,
and
that
could
result
in
the
event
being
dispatched
against
a
different
origin,
because
but
but.
E
The
event
was
being
dispatched
to
frame
right,
so
at
that
point,
why
is
that
even
directly
go
to
the
frame?
Why
is
it
like?
Why
are
we
doing
the
second
ray?
Keep
this
thing
in
the
main
thread
that
determines
to
be
a
like
a
different
location.
That's
like
that
makes
no
sense
to
me.
I.
D
The
test
is
on,
it
is
on
an
element
and
the
the
element
that
was
hit
needs
to
be
determined
by
the
test
algorithm.
So
we
there's
a
there's
a
first
hit
test
that
can
be
done
at
like
a
frame
basis,
that's
efficient
and
then
later,
when
the
actual
event
is
sent
to
script,
it
would
need
to
do
to
determine
the
exact
element
on
in
the
Dom.
That
was
right.
B
E
D
E
Okay
in
your
description,
let's
make
this
example
very
simple
right.
You
have
a
mainframe
and
I
let's
say
you
have
a
child
frame,
a
right
right
and
you're,
saying
that
in
each
of
the
so
in
china
frame
a
is
a
cross
loading.
You
hit
this,
like
a
user
clicks
on
the
screen,
right,
mm-hmm
user
clicks
on
screen
and
we
determine
that
the
click
is
up
is
upon
the
frame
a
right,
and
then
we
decided
that
that's
a
cross
so
G.
So
we
say
that
is
pending.
E
Will
dispatch
event
in
a
frame
you're
saying
that
between
the
time
we'll
send
that
event
to
the
mainframe?
Something
happens
because
it
like
a
cross
process
of
crack
thread.
So
now
the
frame
is
sliding
down
right.
So
now
the
suppose
the
original
coordinate
user
click
it's
no
longer
inside
a
and
in
the
main
frame
right,
but
that's
completely
Iravan
irrelevant
like
we
can
determine
at
the
time
we
have
determined
that
event
goes
to
a
there
at
the
push
them
to
the
a
and
a
sendai
relative
push
them
to
a.
E
C
E
C
D
Just
the
way
like
I,
think
you'd
read
hit
test.
That's
sorry,
good
I
think
the
semantics
really
is
suggesting
could
be
implemented
pretty
easily
yeah.
When
is
input
pending
causes
the
event
to
be
observed
in
the
queue
then
we
make
sure
to
dispatch
it
in
the
manner
rios
case
suggesting.
I
think
that
would
be
fine,
in
fact,
because
of
the
presence
of
a
synchrony
between
multiple
multi
process
loop.
If
type
scenarios
you
can
already
have.
C
Yeah
ought
to
think
about
its
more
but
yeah.
That
sounds
good.
Okay,
I,
don't
think,
there's
anything
like
fundamental.
That
prevents
us
from
doing
that
and
they,
like
the
only
the
only
real,
a
constraint
that
the
API
imposes
is
that
a
frame
may
not
detect
an
event
that
ends
up
getting
dispatched
to
a
different
origin,
which
I
want
to
make
sure
was,
like
very
clear,
was
respected
by
the
implementation.
Irrespective
of
this
case
right.
D
D
What
Andrew
was
suggesting
that
in
in
these
scenarios,
where
we
notice
that
something
is
dirty
between
the
two
between
these
input
pending
call
and
the
actual
event
dispatch,
then
throwing
away
the
event
rather
than
targeting
it
at
some
other
origin,
would
avoid
a
security
issue
where
the
other
one
would
notice
that
it
got
an
event.
Despite
is
afoot
pending
being
but.
E
D
D
D
G
C
C
But
so
this
is
like
a
simple
timeout
based
solution
was
mostly
interested
in
gathering
people's
thoughts
on
whether
or
not
it's
like
it's
not
the
most
idiomatic
thing,
but
effectively,
considering
a
blocks,
rendering
it's
a
fairly
obvious
mitigation
to
the
situation
where
you
would
like
yield.
Non-Input
events,
of
course,
since
there
won't
be
any
deterministic
sources
of
input.
In
many
cases,
I.
E
C
D
Frameworks
no,
but
we
have
multiple
Google
properties
that
really
want
this
feature.
For
the
exact
same
reasons,
Facebook
is
excited
about
it.
The
ads
team
has
had
a
very
positive
experience
in
the
origin
trial
in
terms
of
reducing
event
queuing
delay,
the
same
thing
that
Facebook
observed
in
in
their
origin
trial,
and
there
were
some
prototypes
from
G
suite,
demonstrating
that
they
could
improve
page
load
time
by
yielding
less
when
there's
no
input.
D
G
A
D
B
G
A
B
That'd
be
great,
so
this
is
something
that
I
presented
that
a
little
bit
at
TPACK
last
year.
I
don't
have
any
new,
slides
or
anything
to
talk
about
it,
but
it's
something
that
we're
still
interested
in
pursuing
so
from
a
monitoring
perspective,
resource
timing.
Data
today
is
helpful,
but
it
often
does
not
give
the
complete
picture
of
everything
that's
being
fetched
on
a
page,
a
big
part
of
that
is
due
to
cross
origin
iframes.
B
One
proposal
is
to
have
a
way
for
cross
origins
to
possibly
opt
in
to
sharing
their
data,
and
you
know
the
the
care
here
would
be
for
things
like
ad
providers
that
want
to
show
that
they
are
performing
well
to
open,
open
the
the
curtain
a
little
bit
and
share
all
the
data
that
is
being
fetched
from
their
cross-origin
iframe.
That
they're
loading
for
content
from
I
would
imagine
you
know.
Social
widgets
are
probably
in
the
same
boat
as
well.
B
A
big
thing
that
we
found
was
a
lot
of
this
content
is
at,
but
there's
a
lot
of
things
that
are
being
hidden
by
cross-origin
iframes.
So
one
of
the
takeaways
from
TPACK
that
I
got
from
the
group
was
to
try
to
find
besides
us,
you
know
other
other
concrete
examples
of
places
that
may
want
to
use
this
I
have
spoken
with
a
couple.
B
Customers
of
ours
in
general,
customers
of
em
pulse,
want
greater
visibility
and
more
complete
and
more
accurate
visibility
into
everything.
I
guess
I
could
probably
find
a
customer
statement
if
that
would
help,
but
other
other
people
that
have
chimed
in
on
the
thread
was
actually
from
the
Google
Display
and
video
ads
team,
where
it
sounds
like
they
kind
of
want
the
same
thing.
A
lot
of
their
monitoring
of
the
content
on
the
network
is
hidden
behind
these
iframes
or
in
several
iframes
deep.
B
If
you
will
to
even
so-
and
you
know,
I've
spoken
with
a
couple
other
companies
that
are
doing
a
lot
of
this
that
are
trying
to
get
better
insights
into
ads
and
they've,
resorted
to
doing
synthetic
monitoring,
basically
lab-based
load
and
add
in
in
singularity
into
a
headless
browser
measure.
From
that
point
of
view,
so
they
can
get
a
holistic
view,
but
I
would
see
some
synthetic
is
not
the
real
world
and
you'll
get
a
wide
variety
of
different
contents
and
different
ads
and
different
performance
and
different
delivery
and
everything
out
in
the
real
world.
B
B
Initially
I
don't
propose,
we
could
either
you
know,
reuse
the
timing,
Allah
origin
header,
which
today
lets
you
get
access
to
the
performance
breakdown
or
we
could
add
another
similar
header,
like
timing,
allow
resources
or
timing,
allow
origin
resources
or
something
that
would
be
that
explicit
opt-in
mechanism,
I
think
the
based
on
feedback
from
a
couple
of
people
in
the
thread.
The
the
latter.
B
Think
kind
of
I
listed
a
couple
proposals
in
the
github
issue,
but
I
think
at
the
end
of
the
day,
the
one
that
I,
like
the
best
is
a
extension
to
performance
observer,
where
you
would
have
a
flag
called
bubbles
or
something
similar
where
all
subframes
you
know,
child
grand
grandchildren,
great-grandchildren
frames
would
bubble
up
to
the
top
level
performance
observer.
If
you
had
registered
it
that
way
and
if
the
crossroads
and
iframe
child
frame
had
opted
in,
then
you
would
also
get
the
bubbling
from
those
cross
origins.
B
B
B
You
know
from
our
point
of
view:
we,
like
you,
know
the
more
accuracy,
the
better
you
know,
I
think
some
of
the
big
use
cases
for
us
or
things
are
on
page
weight.
So
we
certainly
want
access
to
the
number
of
bytes
and
URLs
if
it
has
to
be
limited
to
by
domain.
That
would
still
work,
but
you
know,
at
the
end
of
the
day,
the
full
URL
will
give
our
customers
the
ability
to
dig
into
issues
more
so
that
that's
kind
of
where
the
hope
of
all
there.
The
way
the
proposal
is
I.
B
You
know
I
I,
guess
I'm,
not
sure
from
the
group,
what
next
steps
or
if
there
is
any
more
convincing
that
needs
to
be
done
or
I'm
more
than
happy
to
try
to
put
a
little
more
effort
into
getting
actual
non-us
and
Google
people
to
actually
say
they
would
want
this
as
well,
but
I
feel
like
it
would
be
good
from
just
a
holistic
view.
Ability
of
the
web
perspective
for
Rome
to
be
able
to
access
the
data
and
again
I.
Don't
expect
all
ad
providers
to
actually
opt
in
here.
A
Yeah
from
my
perspective,
I
think
that
the
first
step
is
to
figure
out
whether
this
increases
the
security
surface
of
you
know
that
resource
timing
opens
up
in
terms
of
transfer,
statuses
and
figuring
out
transfer
sizes
for
credentialed
resources,
because,
as
I
said,
we
have
a
few
issues
opened
up
on
that
that
we
will
potentially
discuss
afterwards.
If
we
have
time
and
if
not
in
two
weeks,
so
I
think
we
need
to
examine
that
to
see
if
it
doesn't
increases
our
risk.
A
F
A
Think
it
will
cover
the
use
case,
but
I
don't
I,
don't
think
that
most
of
these
third
party
iframes
right
now
are
being
request.
Credential
is
so
they
will
have
to
change
the
way
that
they
operate
in
order
to
you
know
actually
opt
in
if
well
were
limited
to
only
credential
Asst
resources,
I
think
I.
A
But
I
don't
think
it
cascades,
so
you'll
have
to
also
make
sure
that
all
other
reasonable
quality
thing
that
gets
reported
up
is
also
only
credential
Asst,
which
would
mean
that
they
would
have
to
change
a
lot.
Unless
we
have
some
meta.
You
know,
I,
don't
know
if
it's
part
of
a
Corp
and
co-op
we
plan
to
have
some
sort
of
you
know,
fetch
everything,
credential,
it's
kind
of
mode
I,
don't
know
a
bore.
You
know
they
Morgan,
but
course
mode
I,
don't
know.
If
that's
planned
to
be
a
thing.
A
F
G
G
Don't
really
have
a
concern,
but
I
mean
I.
This
is
a
very
real
and
pressing
problem
and
I
guess:
can
we
take
a
step
back
a
little
and
say
the
way
this
proposal
is
framed
right
now
it
seems
framed
or
large,
hosting
and
CDN
providers
to
exert
influence
on
ad
providers,
but
I
would
rather
see
something
like
timing
allowed
cross
origin
that
actual
site
providers
could
come
in
and
put
in
and
mandate
that
the
ads
on
their
platform
be
transparent.
That
ever
considered.
A
That
this
will
significantly
increase
the
security
risk
because
the
site
owner
can
be,
you
know,
evil,
calm
and
it
can
force
facebook.com/
to
be
transparent
about
its
resource
sizes.
In
that
scenario,
or
you
know,
we
could
have
some
feature
policy
that
will
force
basically
say
my
third
parties
don't
load
unless
you're
being
transparent.
That
is
potentially
possible.
A
So
maybe
I'm
misunderstanding
you:
what
kind
of
power
are
you
aiming
for?
I
mean.
G
Like
just
as
a
site
provider
now
that
doesn't
really
have
it
much
control
over
the
ads
being
shown
on
their
page
like
it
would
be
nice
for
them
to
occasionally
be
able
to
audit
that
now
it's
saying
like
all
the
time
but
like
at
specific
times,
I
could
see
a
use
case
where
site
owners
say
I
just
want
to
know.
What's
going
on
on
my
site,
like
so
from
you
know
this
this
minute
to
this
minute:
I'm,
gonna,
I'm
gonna
just
do
some
benchmarking
and
see
what
the
total
page
weight
is.
G
An
accurate
and
animatable
way
on
my
site.
I,
don't
think
that's
possible
right
now.
Clearly,
we've
seen
that
to
pack
that
where
we
really
can't
get
that
info.
B
G
B
B
Yeah
butBut,
I
muscle
I'm,
also
just
pitching
here
from
the
use
of
Joe's
blog,
really
wants
visibility
into
everything
that
has
there,
and
you
know
he
may
not
be
able
to
necessarily
influence
his
ad
providers
to
opt
in
to
this
information.
But
if
there
is
enough
large
sites
that
can
convince
all
of
their
ad
providers
to
opt
in
to
this
information,
the
other
you
know
the
other
sites
benefit
as
well
right.
So
all
the
players
kind
of
benefit.
B
If,
if
this
information
can
get
exposed-
and
you
know
I
like
I'm
picking
that
had
providers
here,
I
think
that's
just
because
it's
an
easy
target.
There
are
a
lot
of
other
things,
social,
widgets,
etc.
That
can
often
hide
some
of
the
weight
pages
behind
them
as
well,
but
no
I
mean
I,
don't
I,
I,
guess
I
personally,
don't
feel
like
it's
just
a
pitch
for
the
benefit
of
large
companies.
I
feel
like
it
is
a
picture
of
the
visibility
of
everybody
on
the
web.
B
That
cares
about
this
information
to
be
able
to
access
it
in
some
sort
of
you
know
convincing
matter.
We
actually
also
I
mean
we've
had
a
couple
customers
also
of
ours.
They
even
just
have
content
on
two
different
domains
and
for
some
reason
they
have
you
know
an
iframe
is
loading.
The
other
content,
like
you
know,
just
a
financial
website
with
two
very.
B
Exactly
yeah
and
and
we've
come
up
with
custom
solutions
for
them
to
pass
this
data
along
through
iframe
messaging,
etc,
but
it
just
felt
like
it
would
have
been
easier
if
they
could
say
hey.
Can
this
other
domain
that
I
trust
opt
into
getting
my
data
in
in
the
standard
way,
so
there's
a
lot
of
like
smaller
scenarios.
Here
too,
it's
just
you
know,
I
guess,
I
I
focused
on
the
biggest
ones.
I
feel
like
that's
one
way
that
the
web
could
be
better
in
general.
If
we're.
G
G
B
B
G
G
A
So
just
a
brief
going
back
to
is
impending
following
a
question
from
Chris:
do
we
have
a
sense
in
the
group
like
can
I
get
a
sense
of
the
group
in
terms
of
adopting
this
work
in
terms
of
interest
from
other
vendors
and
something
along
those
lines?
If
we
were
to
send
a
call
for
a
consensus
on
adopting
this
work
to
the
working
group?
E
A
E
Yeah
I
mean
I,
think
last
discussed
that
it
seems
like
this
is
a
useful
thing
and
a
little
library
all-star
saying
useful
it
is,
you
will
be
useful.
So
that's
good,
right
and
I
think
the
with
the
latest
discussion.
I'll
hit
this
thing.
Priorly
him
dispatching
event
seems
like
there's
not
much.
Privacy
or
security
concern,
I
think.
Obviously,
as
we
review
more,
maybe
we
find
a
new
thing,
but
so
far
seems
okay.
G
A
A
H
It's
just
a
real
quick
update.
We
wanted
to
add
some
debugging
information
to
the
layout
stability
API
and
we
thought
about
different
ways
to
do
it,
and
we
think
that
the
the
best
first
step
would
be
to
add
a
list
of
the
ten
largest
shifted
notes.
We
don't
want
to
unbounded
list
since
there's
a
lot
of
nodes
that
could
be
shifted
and
we
would
ignore
nodes
that
are
like
immediately
inside
each
other
and
we
just
like
feedback
on
that.
B
Well,
I'll
chime
in
first
we're
just
starting
to
add
layout
instability
to
boomerang.
You
know
we're
looking
at
cumulative
layout
shift
etc
for
our
customers
anytime,
we
had
a
metric.
The
first
question
is:
what
does
that
metric
mean
and
how
can
I
affect
it?
Obviously,
there's
a
lot
of
communication
that
has
to
go
on
around
explaining
the
metrics
like
this,
but
the
more
debugging
information
that
we
can
get
and
whatever
way
we
can
get,
it
is
always
helpful.
B
The
having
you
know
from
a
first
glance,
from
the
data
that
we've
looked
at
having
a
list
of
nodes
top
few
nodes,
whatever
it
is,
some
just
main
contributors.
If
you
will,
we
would
probably
try
to
collect
that
data
and
include
it
along
as
like
the
supporting
information
for
us
for
why
the
metric
was
computed
in
the
way
that
it
was
computed.
So
it
sounds
at
first
blush
like
a
really
good
idea.
A
A
Area
so
like,
on
the
one
hand,
we
have
so
there's
a
proposal
from
my
quest
on
taking
the
definition
of
secured
context
to
the
next
level
and
defining
what
he
dubbed
secure
contexts,
which
also
includes
some
variant
of
Corp
and
Co,
app
and
co-op
in
terms
of
isolation
and
in
terms
of
so
transport,
isolation
and
I.
Forget
the
third
part
of
it,
but
generally
I
think
that
the
part
that
we're
mostly
interested
in
is
isolation.
So
in
the
world.
We're
in
process.
A
Like
you
know,
higher
granularity
timers
where
for
the
rest
of
the
web,
we
can
keep
performance
dot
now
in
the
state
that
is
today,
which
I
believe
is
around
millisecond
for
everything
that
is
not
chrome
and
in
chrome
in
non
isolated
environments.
It's
clamped
to
one
hundred
like
tenth
of
the
millisecond
hundred
nanoseconds.
A
So
I
still
plan
to
talk
more
to
Mike
about
this
specific
proposal
and
understand
if
there
is
anything
there
in
terms
of
the
threat
models
that
I'm
missing,
but
from
Europe
like
from
this
group's
perspective,
does
the
idea
of
the
fighting
more
secure
contexts
in
which
we
can
have,
for
example,
more
granular
timers,
or
provide
basically
block
the
memory
API
behind
like
it's
something
that's
available
to
those
kind
of
contexts?
Does
this
make
sense,
or
are
there
any
objections.
A
Does
it
make
sense
from
your
perspective,
in
that
kind
of
context,
to,
for
example,
expose
the
memory
api's
that
we
talked
about
I
believe
in
the
face
to
face,
and
potentially
also
expose
higher
precision
timers
in
those
scenarios,
assuming
that,
assuming
that
the
main
threat
from
high
precision
timers
is
indeed
the
various
processor
timing
attacks?
Well,.
E
A
So
I
said
not
sure
I
got
you
there.
Can
you
elaborate.
E
G
In
general,
I'm,
a
man
I'm,
a
fan
of
having
people
had
to
use
new,
the
high
precision
timing
and
the
extended
memory
stuff
I'm,
really
a
big
fan
of
having
new
things
that
people
have
to
opt
into
for
that.
Instead
of
overloading
existing
things
like
I'm,
a
game
person
or
whatever
like
I'd,
much
rather
see
it.
G
G
A
Okay,
and
so
thanks,
that's
helpful
feedback.
Otherwise
we
have
three
new
issues
open
on
resource
timing.
A
A
A
So
we
are
out
of
time,
but
just
in
a
minute,
I
thought
about
maybe
eliminating
the
cookie
headers
from
the
transfer
size
or
somehow
applying
some
other
rules
or
some
fuzzing
for
credentialed
resource
patches,
but
letting
credentialed
fetches
report
whatever
it
is
that
they're
reporting
now
because
it
doesn't
expose
anything
beyond
access,
control,
our
origin
or
something
along
those
lines.
I
think
we'll
talk
more
about
those
options
in
the
future
call,
but
just
as
a
heads
up,
okay.