►
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
A
A
At
the
same
time,
talking
to
folks
who
use
this
attribute,
as
did
I
mentioned
now,
it
is
critical
in
order
to
deploy
and
maintain
various
protocols
so
knowing
to
split
your
traffic
between.
Oh,
this
is
just
H1
clients
versus
H3
clients.
A
Is
the
critical
capability
and
I've
been
thinking
a
bunch
about
how
we
can
you
know,
maintain
the
use
cases
while
at
the
same
time,
hey
Pete
thinking
a
lot
about
how
we
can
maintain
the
the
use
cases?
A
While
you
know
removing
this
capability,
which
I
think
is
not
really
like,
I,
don't
think
it's
a
huge
privacy
issue
when
we're
talking
about
H1
versus
other
protocols
but,
for
example,
for
H2
versus
H3
they're,
starting
to
look
very
similar
in
not
necessarily
detectable
in
other
means
and
yeah,
basically
we're
thinking
about
ways
to
to
resolve
this
it
in
a
way
that
will
maintain
the
use
cases
with,
but
without
the
risk.
A
Then,
for
but
there's
an
issue
around
timing
about
origin
in
history.
That's
from
my
perspective,
like
potential
history
leaks
but,
from
my
perspective
can
be
closed.
A
lot
of
that
is
addressed
by
cash
partitioning
and
generally,
like
General
partitioning
of
like
cash
and
network
state
and
and
I
believe,
like
I
I,
have
a
comment
on
the
issue
asking
whether
it
can
be
closed.
That
was
never
addressed,
so
it
would
be
great
if
we
could
get
you
know
someone's
attention
to
either.
A
Like
close
the
issue
or
continue
the
discussion,
if
there
are
still
unaddressed
bits
and
then
regarding
timing,
allow
origin
semantics
and
the
expansion
of
semantics
over
time.
This
is
indeed
something
we
did,
and
indeed
something
we
sort
of
regret,
and
we
have
an
ongoing
efforts
to
basically
improve
our
overall
opt-in
story
and
align
the
various
timing
and
the
various
information
that
Tamil
origin
currently
exposes
basically
break
it
up
into
Network
level,
information,
origin
level,
information
and
resource
level.
A
Information
we're
talking
about
origin
will
be
some
sort
of
Declaration
about
the
resource
in
other
types
of
timings
will
be
either
pushed
into
aggregated
reporting,
which
we
talked
about
the
other
day
before,
while
we
run
around-
and
basically
this
is
a
mechanism
that
I
hope
we
would
be
able
to
use
in
order
to
report
some
things
in
aggregate,
but
not
for
a
specific
user,
preventing
them
from
being
a
privacy
issue,
but
still
maintain
their
usefulness.
A
For
example,
DNS
reporting
DNS
times
was
one
of
them,
because
they
have
no
real
implications
on
a
single
user,
but
they
do
have
like
they
are
something
you
want
to
like
monitor
an
aggregate.
A
So
there
is
ongoing
work
to
basically
undo
some
of
the
expense
semantic
expansion
work.
We
did
and
make
sure
that
the
opt-in
makes
sense
from
a
developer
perspective
and.
A
Yeah,
okay
and
then
there's
the
issue
of
deployability
and
monitoring,
which
I
opened
a
tag,
design
principle
for
which
I
strongly
believe
that
those
two
are
critical
for
enabling
modern
development
preventing
regressions,
enabling
the
evolution
of
the
web
platform,
both
from
a
security
perspective,
as
well
as
from
ease
of
you,
know,
easing
deprecations
and
finally,
for
ensuring
yeah
that
the
sites
are.
A
You
know,
experience
the
way
that
we
want
them
to
be
experienced,
and
there
are
a
couple
of
issues
that
let's
touch
on
that
one
is
specific
against
the
reporting,
API
infrastructure
and
the
other
is
around
ancillary
uses.
I
have
to
admit
that
I
had
to
look
up
ancillary
and
it
actually
seems
like
it.
A
It's
the
like,
fits
the
purpose,
basically
providing
necessary
support
to
the
primary
activities
or
operation
of
an
organization,
institution
industry
or
a
system
and
I
think
that
the
like
necessary
here
is
the
keyword
and
from
those
issues.
There
are
various
discussions
around
like
whether
it
is
you
know
something
that
users
can
opt
out
of,
or
have
to
opt
into,
and
essentially
I
think
that
we
need
to
make
a
clear
distinction
here
of
versus
transport.
A
The
reporting
API
is
just
an
infrastructure
API,
similarly
for
the
beacon,
API
or
the
future,
pending
Beacon,
API
or
unload,
Beacon
or
I,
don't
remember
much
yeah
whatever.
Yes,
they
are
similar
to
fetch
and
if
specific
data
is
sensitive,
we
need
to
talk
about
the
data
sensitivity
and
talk
about
whether
we
should
expose
it
at
all,
but
in
a
global
and
holistic
way,
and
talking
about
like
the
reporting,
API
more
specifically
and
what
data
it
currently
provides.
A
It
has
very
different
buckets
and
very
different
categories,
so
we
have
CSD
violations,
document
policy
violations,
Co-op
co-app
and
those
are
all
basically
enablers
to
deploying
security,
new
security
Primitives
on
the
web,
because
websites
cannot
deploy
them
without
like
without
risking
you
know
regressing
or
causing
severe
outages,
and
they
need
these
report
only
modes.
In
order
to
deploy
those
security
policies
safely,
then
we
have
application
reports
who
we
have
a
breakout.
A
We
had
a
breakout
session
yesterday
about
the
their
criticality
towards
the
web's
Evolution
and
our
ability
to
deprecate
old
and
busted
web
features,
and
then
there's
also
interventions
which
you
know
some
engines
may
choose
to
create
various
interventions
on
the
website's
content,
and
this
enables
the
website
to
know
about
that.
We
have
crash
reports
and
then
we
also
talked
about
with
the
accessibility
folks.
We
talked
about
maybe
surfacing
accessibility
issues
and
severe
performance
issues
through
the
reporting
API.
A
So
there
are
very
different
types
of
data
writing
over
this
interceptor
and
then
there's
the
question
of
what
problem
are
we
trying
to
solve
with
you
know,
having
users
up
in
or
up
out
and
to
this,
to
this
infra
or
to
the
data?
Are
we
trying
to
prevent
overexposure
of
data?
Are
we
trying
to
save
users
battery
their
data
plans
or
something
else
entirely?
It
is
not
quite
clear
from
either
of
the
issues
what
what
it
is
we're
trying.
What
what
user
problem
are
we
trying
to
address
here?
A
So
why
not
have
some
sort
of
an
infrastructure,
opt-in
or
opt
out,
because
as
long
as
the
data
is
available
by
other
means,
developers
will
figure
out
ways
to
gather
that
data
and
send
that
data
out
and
like
adding
friction
to
the
well-lit
path
that
we
want
developers
to
take
will
cause
them
to
take
Shader
alleys
and
we'll
discourage
them
from
migrating
from
the
haki
apis
that
are
user,
hostile
that
there's
either
we're
using
or
are
still
currently
using.
A
It
will
prevent
them
from
moving
to
the
nicer
and
hopefully,
more
user-friendly
apis
like
Beacon
Light
reporting
that
provide
them
a
cleaner
way
of
sending
that
data
up
and
of
gathering
the
data.
Because
a
lot
of
the
performance
data
is
also
something
that
developers
can
deduce
and
have
deduced
from
load
events
from
set
timeouts
from
graphs.
But
all
of
these
have
performance
costs
as
well,
and
we
want
developers
to
have
other
ways
of
gathering
the
data
without
the
without
those
costs
and
okay.
A
And
if
we
talk
about,
why
not
have
data
opt-in
or
out
so
so.
First
of
all,
for
a
lot
of
the
data
there
is
like
I
think
it
would
be
so
before
we
talk
about
bias
for
a
lot
of
the
data.
There
is
no.
We
cannot
really
up
developers
out
of
that
data
without
breaking
website
without
breaking
content
that
they
rely
on
or
without
providing
critical
functionality.
A
A
Other
than
that,
there's
the
issue
of
data
bias.
If
we
it's
a
slice
of
the
population
will
opt
out
of
this
data,
it
will
mean
we
will
have
blind
spot
when
looking
at
the
data
from
like
for
deprecation
reports,
for
example-
and
we
see
in
Chrome
that
we
have
like
in
Chrome
ER
collecting
data
regarding
feature
use
in
certain
segments
of
the
population
are
some
somewhat
invisible
to
us
and
that
causes
us
to
potentially
make
bad
decisions
when
moving
forward
with
deprecations
that
are
then
used
by
those
segments
of
the
population.
A
So
reporting
API
is
essentially
a
way
for
us
to
recoup,
so
not
for
us
Chrome,
but
for
us
as
a
community
to
recoup
that
visibility
and
have
so.
If
we
don't
know
about
that,
then
sites
will
know
about
that
and
do
something
about
those
deprecated
features.
But
if
we
reintroduce
the
same
bias
to
this
to
the
data
gathered,
then
this
will
result
in
a
very
similar
like
very
similar
blind
spots.
A
Finally,
I
heard
a
lot
of
good
analogies
from
privacy
folks
regarding
brick
and
mortar
stores
about
us.
We
the
fact
that
we
don't
want
to
walk
into
a
store
and
have
their
security
cameras
officially
recognize
us
know
what
we
did
in
other
stores
and
then
have
someone
follow
us
and
deal
with
us
about
things
we
may
or
may
not
want
to
purchase
there.
I
think
those
analogies
are
reasonable
ones.
A
At
the
same
time,
putting
opt-ins
on
this
kind
of
data
would
be
akin
to
users
being
able
to
turn
off
user
counter
like
if
we
have
visitor
counters
and
stores
that
prevent
stores
from
having
you
know
too
many
too
many
people
in
them,
or
if
we
have
sensors
and
stores
that
detect
that
a
shelf
is
empty.
We
don't
want
individual
Shoppers
to
be
able
to
turn
off
those
means
that
will
prevent
the
store
from
functioning
properly
and
beyond
that.
There
is
no
reasonable
expectation
that
individual
Shoppers
will
be
able
to
do
that.
A
A
Websites
are
wrongfully
collecting
about
their
users,
where
it's
not
the
case,
in
my
view,
or
if
it
is
the
case,
we
should
talk
about
specific
slices
of
data
where
this
is
indication
you
know,
and
finally,
I
really
like,
like
looking
over
the
issue.
I
really
like
this
quote
from
Jeffrey,
where
we
have
Collective
interests
in
aggregating
data,
which
should
be
managed
socially
rather
than
just
individually.
I.
A
Think
that
we
we
need
to
look
at
what
will
make
the
web
platform
prosper
in
a
holistic
way
and
yeah,
that
that
seems
reasonable
and
it's
yeah
based
on
a
paper
that
I
didn't
read
because
it's
70
pages
and
it
was
6
a.m
this
morning,
but
it
seems
insightful
so
yeah
with
that.
Let
me
stop
the
recording
and
we
can
chat.