►
From YouTube: WEBRTC Virtual Interim January 14 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).
B
B
B
B
B
A
So
we
decided
some
time
ago
that
we
will
aim
for
whenever
we
have
to
pay
to
dispatch,
we
will
also
change
the
tests
test,
the
new
behavior
this
is
behavior.
This
is
something
that
has
been
mandated
by
other
working
groups
in
the
WTC
mwg
and
met
with
some
success
there
at
least
that's
what
I
came
so
what's
been
happening
instead.
A
Is
that
well,
people
have
been
making
changes
to
this
back
other
clarifications
or
extension
source,
really
pointing
out
what
meaning,
what
this
tech
needed
to
say
and
then
nobody's
glancing,
we're
about
it
until
someone
picks
a
person
but
mostly
personally,
and
tries
to
implement
the
state
change
right.
The
test.
A
Also,
the
policy
is
focused
on
tests
and
we
know
from
from
experience
that
we've
got
from
tests,
can
test
everything
and
we
don't.
We
have
better
tools,
namely
kites
for
doing
things
like
interrupts
testing,
but
we
have
any
policy
established
around
actually
making
sure
high
tests
are
written
when
needed
and
John
I
looked
at
so.
C
It
basically
failed
a
lot
of
things
it
was.
It
was
not.
You
had
to
update
it
all
of
them
anyway.
I
think
right,
right,
I
think.
If,
if
it's
a
matter
of
tracking
which
features
need
to
be
implemented,
it
would
be
the
better
policy
to
save
file
a
bug
on
browsers
right.
If
you,
if
you
want
really
good
test
coverage,
that's
that's
in
my
experience
only
happening
when
someone
digs
down
and
starts
implementing
the
things
and
think
about
all
the
edge
cases.
It.
D
Really
depends
on
the
actual
bug,
but
it's
fixed
when
you
have
like
a
big
you
proposal
like
a
brand
new
API.
Of
course
you
might
not
have
all
the
tests
and
it
might
be
good
to
wait
for
the
first
implementation.
But
when
it's
like
a
bug
fix
we
a
small
change.
We
should
have
a
WP
key
issue
and
we
should
have
a
test
and
we
should
only
merge
a
change
when
the
develop
test.
D
B
My
basic
question
is:
do
we
know
where
we
are
and
where
the
biggest
holes
are,
because,
obviously
we
we
don't
have-
we
just
you
know,
are
in
the
process
of.
We
either
have
finished
the
final
CR
or
are
about
to
do
so
so
at
least
we
have
a
spec
and
I
guess.
The
question
is:
do
we
have
the
data
at
least
to
give
a
true
picture
of
where,
where
we
are
I.
E
E
F
F
G
F
So
it's
tricky
because
when
you
have
an
implementation,
it's
probably
more
likely
to
be
correct.
So
you
don't
need
a
review.
But
if
you're
yeah
I
will
say
that
for
some
of
the
latest
features
we
added
that
was
for
even
for
perfect
negotiation.
There
was
one
feature
where,
if
which
one
worked
chrome
had
implemented
it
before
we
did,
and
it
was
tremendously
helpful
to
already
have
the
web
platform
tests
so
that
when
you
can
write
your
implementation
towards.
B
F
C
Ownership
is
a
problem:
okay,
in
theory
we
own
it,
but
in
practice
you
know
whoever
implements
the
feature
takes
ownership.
That's
when
you
see
these
good
tests.
Alright
and
well,
you
see
the
you
know
things
getting
stuck
in
reviews
because
there's
nobody
actively
looking
at
these
things,
yeah
so
I
mean
if
we'd
like
I,
think
that's
reality.
I
think,
if
we
we
need
either
need
to
have
resources
for
this
or
we
need
to.
C
B
I
mean
certainly
at
this
point,
because
we're
either
have
a
final
CR
or
about
to
have
one.
We
can
certainly
do
the
no
tests,
no
merge
policy,
at
least
to
avoid
piling
up
more
debt.
I
guess
my
question
is:
is
there
something
we
can
do
with
Dom
around
the
Interop
report
to
try
to
get
a
clearer
picture
of
where
we
most
need
to
help?
Because,
if
we're
going
to
ask
for
resources,
we
need
to
be
clear
what
we're
asking
for.
B
B
B
So
I
guess
one
thing
I
can
volunteer
to
do
is
to
actually
look
at
the
tests.
We
have
I
think
you
in
some
cases
you
actually
need
to
review
the
test
code
to
understand
what
the
stuff
is
really
doing,
and
what
it's
missing
so
I'm
willing
to
do
that
and
at
least
provide
an
opinion
on
where
I
think
our
coverage
gaps
are,
which
we
can
argue
about.
B
E
E
For
four
again
from
a
purely
formal
WZ
process
perspective,
the
only
thing
that
matters
is
getting
double
independent
fragmentation
of
each
feature
with
our
mobile
on
desktop
anywhere
else,
doesn't
really
count,
of
course,
for
we
all
interrupt
these
matters,
but
then
we
get
out
of
purely
process
considerations.
The
reason
that
for
start
sizing
kite
would
be
usefully
that
we
would
get
clearer
picture
that
the
value
is
reported
by
right.
G
B
B
H
Would
argue
that
testing
the
existence
and
compliance
of
the
signature
of
the
API
is
doable
in
any
given
case,
but
testing
that,
in
certain
cases,
returning
the
real
value,
especially
when
the
network
is
involved
or
right
now
you
need
a
different
peer
or
you
need
an
exceptional
like
civil
cast.
We
know
since
lisbonne
right
that
are
the
design
of
WPT
will
not
allow
us
to
do
right.
B
H
To
share
my
result
with
Tom,
even
if
he
for
me
running
WPT
moving
kite,
even
the
non
extra
one,
I
had
put
an
action
item
on
my
list
in
Fukuoka
sighs
check
with
Tom
the
coverage
tooling,
which
I
haven't
done.
So
it's
my
fault
so
Dom.
When
would
you
have
time
to
interact
with
me
and
help
me
give
you
the
data
I
might
have.
E
H
E
H
B
By
the
way,
I
would
mention
something
dumb,
which
is
that
I've
been
investigating
all
the
differences
between
chrome
and
edge
in
the
test.
Results
and
I
found
a
whole
bunch
of
spurious
results
in
the
Interop
matrix,
but
they're
relatively
minor.
Basically,
it's
got
to
do
with
getusermedia
failures,
so
yeah.
E
H
H
D
D
D
D
A
A
E
B
At
some
point,
we
were
gonna
have
a
final
CR
which
hopefully
will
be
a
real
fine
I'll
see
her,
and
then
you
know
that
that
even
that
you
know
after
the
final
CR
right
I
mean
holding
stuff
up.
Maybe
not
terrible
I
mean
hopefully
right
we're
not
if
we're
holding
something
that
really
matters
and
we're
not
at
fine
I'll
see
her.
I
B
E
C
I've
summarized
the
discussions
as
no
desire
to
abandon
testing
policy.
Son
decided
to
enforce
no
tests,
no
merge.
If
writing
test
is
easy
best
to
merge
tests
in
PR.
At
the
same
time,
the
some
flexibility
might
be
in
order.
Editor's
need
merge
rights
on
WPT
repo,
and
we
should
incorporate
kite
into
the
testing
report
and
editor
calls
should
incorporate
testing
PR
but
fair,
summary
I.
B
F
Right,
let
me
get
some
water
alright,
so
yes,
so
the
main!
So
there's
a
bulk
of
issues
here,
I
added
a
couple
trying
to
break
out
some
of
the
concerns
into
multiple
issues
and
are
really
solved
by
the
same
proposal.
So
that's
why
the
list
has
grown
a
little
bit,
so
this
mostly
was
triggered
by
a
panga
review
in
2090
that
raised
privacy
concerns,
and
so
this
is
my
setting
the
stage
slides.
Why
now?
Basically,
the
private
sea
climate
has
changed
for
legitimate
reasons.
F
Websites
are
tracking
users
big
time,
so
the
thinking
that's
mirrored
by
ping
now
is
that
in
2020,
exposing
all
the
users
devices
beyond
the
one
they're
using
it's,
not
polar
I'm,
not
principal
of
least
astonishment.
This
goes
beyond
fingerprinting,
potentially
revealing
actual
the
private
informations
user
may
not
have
intended
to
share
about
what
they
own
and
have
plugged
in
that
might
be
prototype
devices.
Adult
devices
and
I
was
stuff
suggested
by
the
ping,
and
that
this
is
not
the
minimal
information
needed
to
achieve
user
goals.
The
next
slide
so.
F
Unfortunately,
Firefox
shares
all
labels
instead
of
all
devices,
so
this
change
alone
would
actually
break
the
white
selection
in
fire
and
Firefox,
and
that
would
force
Firefox
if
it
wanted
to
be
spec
compliant
to
grant
all
devices
to
make
it
work,
which
is
worse
for
privacy,
and
it
would
have
no
beneficial
impact
on
any
other
browser
either.
So
that
was
not
the
pings
intention,
so
the
pink
wire
part
is
once
a
privacy
by
default
flow.
Where-
and
this
is
a
quote-
a
site
asks
for
category
or
categories
of
device.
F
So
this
is
in
browser
or
as
we
call
it
in
chrome,
selections
and
the
question
is:
can
the
spec
accommodate
this
and
the
thinking
here
is
that
if
you're
thinking
well,
how
does
it
work
in
our
browser?
And
we
have
a
problem?
I
think
that's
the
wrong
way
to
think
about
it.
I
think
we
need
to
think
how
do
we
make
an
IP
I
that
works
well
in
all
browsers,
whether
regardless
of
how
private
their
choice
is
on
privacy?
F
F
This
brings
up
an
existing
issue.
That's
been
true
for
a
long
time
and
that
there's
also
no
way
to
choose
a
correct
camera
and
microphone.
Upfront
and
most
browsers,
say:
site
so-and-so
wants
to
use
your
camera
and
microphone,
but
it
doesn't
tell
you
which
one
if
you
have
more
than
one,
if
it
picks
the
wrong
one.
The
user
needs
to
correct
it
after
the
fact,
and
also
grant
permission.
E
F
Permission
is
per
device
to
the
wrong
device
ahead
of
times.
This
is
also
a
web
compatibility
issue
because
browsers
may
not
choose
the
same
device.
So
there's
three
interested
parties
that
go
into
the
selection.
It's
the
applications
that
can
influence
the
selections
or
pick
it
entirely.
Based
on
constraints,
then
there's
the
user,
which
may
pick
in
a
picker
like
in
Firefox
or
the
user
agent.
So
three
people
that
might
decide
so
Firefox
is
the
only
one
that
I
know
of
that
shows
that
can
run
microphone.
F
That
shows
which
camera
and
microphone
we'll
be
picked
and
also
lets
the
user
override
that
within
application
constraints
and
the
way
we've
implemented
it
is
that
the
I,
whatever
you
specify
as
an
ideal
constraint,
the
user
may
override,
but
it
does
influence
what's
chosen
by
default.
If
you
don't
make
an
explicit
selection,
but
they
cannot
go
outside
the
constraint
envelope,
so
it
means
you
can't
if
the
application
used
exact
device
study,
for
example,
Firefox
only
prompts
for
that
device.
F
Even
the
wire
UX
in
that
case
is
a
little
misleading
we'd
like
to
improve
that,
but
not
everyone
with
multiple
devices
use
Firefox.
So
we
think
it
would
be
better
if
users
get
to
choose
based
on
how
many
devices
they
have.
What
you
are
they
see
not
based
on
more
Preiser
they
use,
and
maybe
even
regardless
of
permission,
because
it's
the
app's
responsibility
using
constraints
to
remember
on
subsequent
wizard
what
this
user,
what
devices
they
like
to
use,
and
so,
if
the
site,
the
gate,
set
responsibility
and
use
its
indecisive
constraints
on
the
subsequent
wizard.
F
F
So
this
is
sort
of
a
minor
issue,
but
today
in
Firefox
you
can
override
its
picker
actually
by
forcing
the
default
device
by
calling
a
numeric
devices
upfront
and
then
grabbing
out
the
first
device
in
the
list
of
the
kind
you
want
and
then
say,
I
I
must
want
to
have
I
want
I
want
to
have
this
one.
Only
and
I
actually
ensure
it's
the
same
behavior
in
all
browsers,
but
we
for
other
privacy
reasons
we
recently
removed
the
by
study
from
manoeuvre
enumerate
devices
unless
you
already
have
gun
permission,
so
this
no
longer
works.
F
F
So
the
fourth
and
final
issue,
I'm
going
to
talk
about,
is
in
content
of
my
selection
itself.
I
would
argue
it's
too
complicated
not
based
on
all
the
features
that
it
offers,
but
has
majority
of
websites
gotten
it
right
in
a
way
that
works
compatibly
across
browsers
and
devices
and
I
think
the
answer
is
no.
F
After
seven
years,
it's
also
not
terribly
exciting,
they're
very
functional,
and
but
they
all
look
alike
and
they
do
the
same
things
and
that's
fine,
but
you
know
so:
let's
wait
against
the
costs
and
the
costs
and
problems
are
mr.
Solis,
the
sole
reason
we
expose
labels
for
all
devices
upfront
and
why
we
fail
ping,
a
review.
It's
also
inherently
limited
by
the
browser's
permission
envelope,
there's
no
way
to
ensure
thinking
it.
You
can't
pick
a
camera
microphone
upfront.
F
We
covered
that
it's
also
clunky
without
persistent
permission,
because
most
web
UX
that
I've
seen
sort
of
lets.
You
gives
you
a
list
to
pick
from,
and
then
you
pick
it
and
then,
if
you're
in
Firefox
and
get
a
permissions
prompt
again
for
that
device,
and
you
basically
pick
it
again
and
it's
also
got
pretty
terrible
web
compatibility.
Especially
everything
seems
to
work
well
in
Chrome,
but
in
Firefox,
we've
had
a
lot
of
issues
where
basically,
every
site
having
to
write
this
on
their
own
has
has
been
a
failure
and
I
use
some
examples
here.
F
F
There
are
some
sites
that
recently
had
to
change
their
permission,
prompts
with
a
new
team
and
had
a
terrible
time
because
effectively
web
developers
end
up
having
to
program
against
two
permission:
models
that
are
quite
different
and
it's
easy.
If
you're
testing
on
the
one
more
permissive
model
that
you
won't
catch,
all
the
problems
in
the
other
mode.
Other
problems
is
that
mobile
devices
usually
can't
open
more
than
one
device
at
a
time.
Unless
you
have
an
older,
Android
tablet.
That
could
do
that
and
that's
actually
hard
to
get
right.
F
It
requires
having
to
stop
the
previous
track
before
you
pick
another,
which
is
also
an
inferior
approach
on
desktop.
So
that's
quite
hard
to
get
right.
A
few
people
get
that
right
and
limited
preview.
Designs
are
inherently
impeded
by
browsers
different
permission
models,
so
you
couldn't
do
you
could
actually
do
mass
previews
and
expose?
You
could
have
a
picker
that
exposes
a
preview
of
every
camera.
F
You
have
on
your
system
and
you
could
pick
that
way,
but
that's
also
exposes
that
it's
actually
a
little
creepy
that
the
site
has
all
that
power
and
inconsistent
user
experience.
Every
site
it's
on
is
on
its
own
to
how
to
figure
out
how
this
interface
should
look.
So
you
see
from
the
two
screenshots
above
they
do
exactly
the
same
thing
and
the
ability
to
customize
this
the
potential
that
hasn't
really
materialized
in
seven
years.
So
there's
no
path
to
privacy
here.
F
So
this
is
my
pitch
in
hindsight.
We
could
have
done
everything
in
Chrome
in
browser
models
on
these
sorts
of
get
display
media
because
we
get
this.
Maybe
we
went
a
different
approach
always
and
the
benefits
here
is.
That
removes
the
needs
to
grant
all
permissions
to
all
devices
up
front
and
it
even
works
upfront
and
you
can
select
up
front
even
though
you
have
given
no
permission
to
the
site.
It
can
still
pick
your
camera.
You
can
still
pick
between
all
your
cameras.
F
You
can
have
previews
that
kind
of
thing,
and
you
may
not
want
to
do
previous
at
that
point,
because
it
can
still
be
a
little
jarring
and
scary,
but
that's
up
to
browsers
on
desktop
users
can
also
improve,
implement
previews
safely,
even
for
cameras
that
aren't
chosen
and
mobile.
The
problem
I
mentioned
earlier
with
different
platforms,
can
be
handled
by
it
more
reliably
by
the
browser's
they
could.
F
They
could
do
tricks
like
a
temporarily
mute,
the
the
single
device
and
shove
a
selector
for
other
devices,
and
then,
if
the
user
cancels
out,
restore
the
old
device
stuff
like
that.
Okay,
so
now
that
we
have,
but
we
have
in
content
device
selection,
how
can
we
have
in
Chrome
as
well?
So
the
idea
here
is
that
we
could
have
a
transition
period
in
chrome
selections.
F
Maybe
better
previous
people
would
prefer
that
on
stage
to
MIT
we
can
remove
label
from
enumerate
devices
and
basically
deprecated
in
content
selection,
so
just
to
clarify
this
would
not
change
anything.
We
we
have
regarding
to
a
device
ID
and
being
able
to
see
number
of
devices
you
have
and
track
label
all
that
would
remain
the
same
now.
I
F
Next
slide,
so
here's
to
the
PR
that
was
proposed
last
meeting
and
has
one
problem
with
it,
but
I'll
go
through
it
again
and
then
just
a
mandate
in
chrome
gum,
selector,
Allah
Firefox's.
When
and
all
that,
when
a
user
we
find
a
user
who
has
multiple
devices
and
the
constraints
don't
reduce
choices
down
to
one.
This
basically
removes
the
user
agent
as
a
decision
maker
in
which
device
to
pick.
F
Basically
can't
get
used
in
media
cuz
coming
out
of
the
okay
of
the
settings
dialog.
It
would
just
call
get
using
me
again
with
what
you
already
had
selected
stuff
like
that,
but
I
would
still
argue.
Most
users
would
not
notice
a
change
because
they
either
only
have
a
single
camera
or
the
website
is
using
exact
facing
mode
to
pick
up
front
versus
back
camera.
But
the
idea
is
that
it
changed
us
to
get
user
media
and
that
you
can
say
please
give
me
a
camera
microphone
that
the
user
has
chosen.
F
F
So
this
is
the
PR
again
and
it
basically
the
it's
not
a
lot
of
spec
change,
but
there's
basically
two
the
permission.
Spec
has
two
algorithms
and
one
is
called
request:
permission
to
use
which
is
actually
designed
for
a
sole
device
and
I
caught
when
I
changed.
The
text
here
actually
fixes
a
bug
that
the
text
I
removed,
you
used
to
say
in
order
to
import
per
device
permissions
which
no
browser
supports.
Yet
the
old
text
exactly
wrong
to
call
request
permission
to
use
without
knowing
which
device
it
is.
F
So
if
you
see
in
the
red
text,
it
says,
consider
this
device
how
you
remember
set
to
any
appropriate
device,
this
device
ID.
So
the
new
text
now
actually
calls
an
algorithm
correctly
request
permission
to
use
and
the
text
change
is
basically
if
the
number
of
unique
devices
sources,
sourcing
tracks
of
media
type
kind
is
candidate
in
candidate
set.
Is
one
then
set
the
device
ID
member
and
request
permission
to
use
the
sole
device,
otherwise
prompt
the
user
to
choose
a
device
with
descriptor.
F
F
When
done
correctly
using
the
exact
constraint,
there
would
be
no
change
in
behavior,
but
there's
a
backward
compatibility
issue
here
with
sites
that
might
use
an
ideal
device,
ID
constraint
on
revisit,
and
that
makes
sense
there
because
you're
basically
saying
I
want
to
remember
the
users
camera
from
last
visit,
but
they
may
have
unplugged
it
now.
So
please
don't
fail.
The
gum
call
like
you
know,
get
the
users
existing
device
if
they
have
it.
F
F
Next
line
is
basically
add
a
new
media
boolean
for
this
new,
hey
behavior,
and
it
could
be
something
like
you
call
navigator
get
me
devices
get
user,
media,
video,
true
and
then
chosen
true,
where
chosen
means
must
be
chosen
by
the
user
or
not.
The
user-agent
would
apply
to
both
audio
and
video
if
present
and
I'm
happy
to
bike
a
name
for
that.
So
basically,
this
is
the
Coppa
where
we
believe
this
new
behavior
is
the
correct
behavior,
but
it's
not
web
compatible.
So
we
put
in
the
boolean
to
pick
and
proposal.
F
C
is
the
same
thing
just
with
a
new
method:
choose
user
media
and
that
avoids
a
boolean
Arg,
which
I
think
most
people
say.
You
know
you
shouldn't
have
boolean
in
your
api's,
but
it
also
feels
like
overkill,
and
everything
else
is
the
same
and
might
falsely
suggest
that
there
are
more
differences
here
than
they
are
might
actually
lead
to
more
refinement
which
could
actually
cause
this
idea
to
stall
and
respect
perspectives.
F
It
would
let
us
put
device
idea
in
the
right
devices
label
behind
some
permissions
and
I
mentally
kill
it.
It
would
give
browsers,
actually
applications
the
choice
upfront,
whether
they
prefer
a
picker
or
not
in
all
browsers.
It
would
work
compatibly
against
all
browsers
it
would.
There
would
be
no
need
for
this.
The
default
device
ID
that
I
spoke
of
earlier,
provided
that
Firefox
gives
up
its
current
camera
microphone.
F
Ticker,
it's
false
and
I
would
give
more
consistent,
behavior
and
the
last
one
is
this
model
no
longer
requires
math
permission
and
browsers
can
handle
previews
and
tricky
platforms.
So
you
get
overall,
better
cross
browser
experience
and
compatibility
and
I
think
that
was
all
the
slides.
So
maybe
we
can
go
back
to
the
slide
that
had
proposals
again
see
didn't
go
back
a
couple
quick.
D
Question
on
Ivar
yeah,
so
initially
you
said,
but
the
big
thing
working
group
was
for
which
closure
of
only
the
device,
but
the
user
granted
access
to
it
seems
that
in
your
proposal,
in
fact,
the
web
application
gets
knowledge
of
all
the
devices
and
all
the
capacities
except
the
label
right,
but
but
to
be
clear.
I
still
think
it
might
be
an
issue
for
anything
work
we
see,
but
its
benefit,
because
label
will
not
be
there.
F
D
F
The
I
think
the
more
important
point
here
is
that
this
is
this
is
trying
to
outline
how
in
Chrome
device
selection
could
work,
and
that
gives
us
an
avenue
that
opens
a
path
to
privacy.
We
now
have
choices.
If
we
want,
we
can
limit
more
information,
the
only
issue
they
filed
what's
on
the
label,
so
if
they
want
to
limit
more
information,
we
now
have
an
avenue
that
where
we
can
do
that,
because
we
can
ask
the
user
these
this
information,
without
involving
JavaScript
and
having
drama
script,
have
the
responsibility
of
building
a
picker.
C
F
F
Right,
but
this
is
this-
is
information
about
the
user
beyond
fingerprint
and
that
I
know
if
you
live
in
the
u.s..
You
probably
get
these
spam
mailers.
Sometimes,
like
you
know,
your
your
insert
make
of
your
car
is,
is
in
need
of
more
insurance
or
something
your
insurance
is
gonna
expire,
the
more
information
you
have
about
a
user,
the
more
you
can
trick
them
with
phishing
and
that
kind
of
stuff
they
could
say.
D
F
F
If
you're
claiming
that
users
understand
that
when
they
say
they
want
to
use
your
camera,
that
you
just
gave
permission
to
all
their
cameras,
I
would
challenge
that
I
think
that's
true
in
all
browsers,
except
Firefox.
At
the
moment
it
says
it's
as
far
as
the
user
understands
they
want
to
use
one
camera
and
you
get
permission
to
all
so
I
think
the
intent
there
is
to
not
be
surprising
and
make
sure
you
have
consent
from
the
user
and
I'm
not
sure
that
counts
as
consent
to
all
devices.
I.
Think.
K
F
So
I
don't
think
the
the
I
could
me
miss
reading
the
ping,
but
I
didn't
take
their
concern
to
be
my
interpretation
of
it.
Wasn't
so
much
that
the
the
spec
allows
browsers
to
make
poor
privacy
choices,
but
so
much
that
the
spec
seems
to
prevent
or
make
it
really
hard
to
make
browsers
that
make
better
choices.
L
F
A
So
I
kind
of
liked
versions,
B
and
C
in
that
for
existing
applications,
where
the
user
grants
permission
to
all
cameras
and
all
microphones
and
therefore
has
the
lead
the
label
has
has
been
read
to
them.
Then
it
would
work
just
as
before
and
right
if
you
want
to
do
something
something
more
privacy
respecting
them.
You
can
do
that
and
I
kinda
like
that
approach.
A
L
A
A
A
I
C
If
we
have
a
in
Chrome
picker
that
I
think
I
think
there's
no
longer
a
need
for
any
of
the
old
ways
and
like
it
seems
it
seems
to
be
the
preferred
I.
If
both
api's
existed,
it
would
seem
like
the
preferred
API
to
go
with,
but
it
also,
if
it's
a
separate
API,
the
downside
would
be
that
unless
people
are
updating
their
code
right
like
like
basically
have
this
privacy
issue
and
by
having
a
boolean
or
a
new
API,
you
make
you
make
you
make
using
something.
That's
good
for
privacy
optional.
C
J
Thing
is
that
I'm
not
doing
it
that
way
would
break
the
web.
Basically,
I
know
that,
for
example,
hangouts
I
mean
well
the
bug
Anita.
You
know
that
it
makes
like
16
getusermedia
calls
just
from
to
something,
so
she
had
16
I,
don't
know
exactly
why
they
do
all
that
in-house,
but
but
but
all
that
stuff
relies
on
the
fact
that
once
they
get
authorization,
they
can
make
a
calls
all
the
time
and
and
and
and
and
the
user
doesn't
have
to
constantly
choose
what
what
device
to
use
for
each
getusermedia
called.
J
C
To
work,
it
seems
like
a
good
approach
that
if
we,
if
we
shape
the
good
way
of
doing
things,
we
were
clear
about,
like
everyone
actually
implements
the
same
thing
and
it's
good
for
both
privacy
and
usability
and
then
compatibility
if
we
get
to
the
point
where
the
new
way
is
clearly
superior
and
then
the
old
way
like
the
thing
about
deprecating,
the
old
way
is,
is
it's
it's
still
gonna
work.
It's
just
gonna
that
you're
gonna
get
spammed
by
prompts
right
like
we
can.
C
C
C
That
we
want
to
avoid
that.
We
definitely
don't
want
to
ship
something
where
suddenly
you
get
prompted
all
the
time
and
there's
no
way
to
get
around
it,
but
if
there
is,
if
there
is
a
viable
option,
that's
you
know
one
line
code
line
away
at
that
point
it
might
be
feasible
to
make
the
old
way
more,
prompting.
E
F
This
is
the
other
problem
with
Firefox
is
picker
and
that
it
only
it's
not
a
reliable
device
picker
by
any
means,
because
it
only
appears
if
you
don't
have
permission.
So
as
soon
as
you
remember
this
permission,
you
don't
get
the
picker
anymore,
so
the
underlying
model
is
at
that
point
where
it's
the
same
as
any
other
browser.
F
So
this
would
be
a
change.
So
talking
about
web
comp
at
Firefox
already
sees
website
extra
prompts
with
it's
a
big
concern
for
us
that
if
people
use
like
you
mentioned
in
Google
meat
and
hangouts,
you
get
a
prompt
for
camera
and
then
you
get
another
prompt
for
microphone.
That's
one
thing,
but
also
other
sites
like
whereby
they
had
now,
but
it
used
to
be.
You
went
into
where
you
first
got
your
initial
product
for
camera
microphone.
F
If
that
wasn't
was
wrong
and
even
to
change
it
go
into
settings
and
you
would
pick
camera
and
it
would
prompt
you
they
fixed.
It
now
said
only
prompts
for
camera,
and
then
you
changed
that.
But
then,
when
you
hit
OK,
you
get
a
prompt
again
for
a
camera
and
microphone,
so
they
fix
it.
Now,
but
there's
a
lot
of
gotchas
web
compatibility,
why?
F
Why
is
that
you
run
into
you,
because
it's
true,
but
it's
like
to
do,
seem
to
call
getusermedia
a
lot,
but
with
this
PR
proposal
a
it
would
actually
be
slightly
worse
than
what
then,
what
you
could
just
see
in
Firefox,
because
Firefox
also
has
this
behavior
built-in,
because
of
how
we
interpreted
the
spec,
but
mostly
to
to
align
with
our
websites,
we're
already
using
getusermedia
that
if
you
already
have
permission
to
a
track
and
that
track
is
one
of
the
choice,
potential
choices
in
the
prompt.
We
want
to
show
you.
F
We
skip
the
prompts,
and
we
always
give
you
that
that
device
and
that
that's
what
that
was
for
web
compatibility
at
the
time
and
also
why
you
couldn't
actually
implement
proposals
a
well
that's.
Why
proposal
a
doesn't
already
work
in
Firefox
split
that
way.
Otherwise
this
one
actually
worked
quite
well.
So
that's
the
change.
That's
being
proposed.
F
Well,
I
should
clarify
that
there's
a
very
little
difference
between
B
and
C
here
other
than
the
API
surface,
so
I
don't
want
to
imply
I
worried
about
putting
it
on
the
slide
because
it
does
imply
and
sort
of
open-ended
down
the
road
there'll
be
a
separate
method,
so
it'll
nothing
have
nothing
to
do
and
we
can
totally
redesign
it.
The
intent
was
here
that
this
is
still
the
same
and
only
get
using
media
call.
You
should
be
using
in
the
future
really
or
should
need
in
the
future
and
the
only
reason
to
call
it.
C
B
C
F
Again,
proposal
C
was
only
meant
as
an
API
surfers
variant
of
promote
the
same
behavior
as
proposal
B,
unless
someone
is
proposing
something
something
else,
a
student
much
the
same
thing.
Yes,
so
in
that
case
the
only
difference
here
trying
to
make
it
an
issue
that
doesn't
really
address
device,
ID
or
the
other
device
in
for
information
I.
Think
that's
an
orthogonal
orthogonal
question
I'm,
not
personally
of
the
opinion
that
exposing
device
IDs
in
this
context,
where
you
already
have
permission,
you
know
I,
think
that's
completely
orthogonal,
basically,
basically
yeah.
E
D
I
think
that
being
working
would
would
say
that
if
you
grant
access
to
one
camera,
why
should
you
know
that
there's
another
camera
somewhere
else
and
what
the
capacities
of
view
of
the
camera
are?
Probably
you
should
not
be
able
to
to
have
that
the
web.
It
should
not
have
that.
The
thing
will
be
right,
or
we
did
say
that.
F
D
F
Hesitate
to
say
that's
going
further
than
this:
PR
is
going
and
I
have
speculate.
I,
don't
wanna
speculate
about
what
the
ping
would
I
wouldn't
want.
The
only
issue
that
I've
filed
their
language
so
far
is
about
the
label,
and
it
says
the
site
gets
access
only
to
the
device
and
label
of
the
hardware,
the
user,
so
life
I
would've
been
working
with
them.
D
E
Don't
think
we
need
now
ping
to
say:
what's
I
mean
if
we
think
this
would
be
a
privacy
improvement
that
we
want
to
make
we
don't
it's
a
pink
blessing
to
do
it
so,
but
I'm
trying
to
assess
how
much
of
it
is
indeed
orthogonal
to
that
discussion
or
not
like
you.
Can
we
to
this
first
bit
and
then
explore
if
it
gets
us
additional
privacy
benefits
or,
as
you
were,
putting
it's
un,
it's
not
worth
it
unless
it
brings
additional
privacy
benefits.
C
I,
don't
think
like
I,
don't
think
you
need
to
decide
like
this
is
sort
of
like
one
step
and
you
can
take
one
step
without
taking
a
second
step,
but
but
I
do
think
the
related
steps
right,
because
if
you,
if
you
make
it
obsolete
to
for
an
application
to
handle
device
selection,
then
suddenly,
why
would
you
need
all
these
these
labels?
So
it's
it
is
relevant,
but
we
don't
have
to
do
both
things
at
the
same
time.
But
it's
worth
discussing
yeah.
D
F
Well,
there
was
a
slide
on
transition,
whether
you
know
do
a
two-step
there's
some
concerns.
Web
compatibility
is
one
and
how
far
we
want
to
go
so
getting
rid
of
the
label
putting
it
behind
on
permissions,
that's
more
of
a
token
solution
and
that
would
only
break
Firefox's
in
content.
Device,
selector
but
and
I
think
the
goal
would
be
to.
If
we
want
to
deprecate
in
content
device
selection,
you
don't
need
label
and
enumerate
devices.
G
F
Well,
numerator
vices:
the
way
we've
changed
it
in
the
spec
lately
it's
there
to
to
assist
javascript
to
build
a
picker
right.
So
if
we
remove
that
task
from
JavaScript,
we
remove
the
need
for
a
numeric
devices
labels
and
probably
any
other
information
that
isn't
necessary
to
accept.
Maybe
the
number
of
devices
so
I
don't
think
that
I
think
it
would
be
really
hard
for
users
to
understand
that
they
give
permission
to
enumerate
their
devices
I,
don't
think!
That's
right!.
J
D
F
L
K
Have
a
slight
very
slight
objection
to
see
in
that
we're
kind
of
forgetting
that
permissions.
It's
not
just
media
permissions,
but
we're
also
actually
giving
local
IP
address
permissions
as
a
side
effect
of
their
city.
Once
you
start
like
we've
got
it
into
our
heads
that
that's
now
associated
with
getusermedia
and,
however
unsatisfactory.
That
is,
but
if
we
now
have
it
associated
with
two
separate
calls
as
well.
This
gets
very.
F
I
think
if
I
were
to
pick
myself,
I
think
I
would
pick
well
I,
don't
think
a
is
gonna
fly,
so
I
think
I
would
pick
B
and
I
like
what
what
Hendrix
said
about
you
know.
This
would
allow
people
to
opt
in
and
we
could
change
the
default
behavior
and
change
it
to
an
opt-out
time.
That's
something
what
we
did
for
I
know:
chrome
did
for
as
the
P
semantics,
for
example,.
I
E
E
Yeah
from
a
purely
process
perspective
again,
if
we
think
the
current
getusermedia
as
is,
is
going
to
remain
as
is
and
is
implemented
correctly,
then
there
is
no
reason
to
deny
that
forever
artists
until
that
extension
is
applied,
but
there
may
be
changes
needed
for
the
extension
in
ways.
Liberals
get
granted
permission
that
would
need
to
be
implemented
at
some
time
that
I'm
unclear
about.
If.
C
We
if
we
don't
change
the
main
spec
but
instead
add
an
extension
spec.
Doesn't
that
mean
that
we
do
the
main
spectrum
from
completing
the
privacy
review?
And
then
we
have
this
and
then
we
by
having
an
extension,
spec
or
less
attention
to
it,
I
guess
for
because
we
do
want
it
implemented
as
well.
Yeah.
B
I
mean
my
problem
is
I,
think
I'm
concerned
about
either
direction
because
currently,
where
you
know
the
ping
folks
are
getting
antsy,
if
we
tell
them
hey
we're,
not
changing
this
they're
likely
to
get
even
more
antsy,
but
on
the
other
hand,
if
we
do
change
it,
we
we
draw
out
the
PR
process,
for
god
knows
how
long
so,
I
don't
know
it's
it's
kind
of
either
way.
It's
like
something's.
B
E
G
C
We
have
we
want
to
go
through
the
privacy
review,
'no
and
actually
pass
it.
Then
then,
the
privacy
aspects
that
they
need
to
be
mandatory,
not
not
optional,
so
I
practice
assuming
we're
gonna.
Do
this
then
then,
at
some
point
the
current
stuff
will
be
removed.
So
it's
just
a
matter
of
how
can
we
ship
this
in
a
way
that
doesn't
great
stuff
too
much
I.
F
G
D
D
F
B
F
E
I
just
want
to
say
I,
don't
think
our
goal
should
be
to
pass
ping
with
you
or
go
shouldn't,
be
good
spec
and
a
good.
We
also
include
privacy,
respect
for
that
specification
and
ping
helped
us
get
there.
They
may
help
us
by
agreeing
or
disagreeing
with
us,
but
ultimately
we
have
to
pick
what
we
want.
E
D
Would
personally
like
that,
we
will
fix
as
much
as
we
can
live
a
current
model
and
we
try
to
move
forward
with
that
as
a
PR
and
a
recommendation,
and
we
also
work
in
parallel
to
a
new
model
and
we
take
the
time
to
do
the
new
model
and
it
will
take
quite
some
time.
It's
it's
not
just
it's
not
a
few
lines
of
code.
It's
not
a
few
lines
in
the
spec.
We
have
a
lot
of
there
and
it's
good
that
we
can
start
both
together.
But
I
would
still
like
that.
We.
D
Basically,
we
would
restrict
Megas
device
info
to
only
the
types
that
are
granted.
So
if
you
go
and
camera
access,
you
grant
access
to
all
the
information
of
the
cameras,
but
not
information
of
the
microphones.
For
instance,
we
could
do
some
additional
improvement
there
without
changing
the
model
of
the
spec,
and
we
can
try
to
pass
up
in
review
with
that
and
push
it
to
recommendation
and
in
parallel
we
start
now
on
figuring
out
the
right
model
that
we
should
have
done
from
the
start.
The.
F
F
F
If
we
look
at
what
Mozilla
would
have
to
do
to
implement
this
chosen
boolean,
we
could
actually
were
actually
pretty
close.
We
already
have
an
in
device
picker,
the
only
problem
with
it,
it's
that
in
the
case
where
you
already
have
permission
to
one
of
the
choices
we
bypass
the
prompt
president,
we
would
not
bypass
the
prompt,
and
that
means
that
in
Firefox
pretty
soon
you
could
do
in
Chrome
device
selection
and
so
would
happen
to
one
implementation,
basically
for
a
very
little
work.
I
appreciate
that
other
vendors
would
need
more
time
too.
F
We
also
have
an
issue
where
that's
already
true.
If
you
in
the
current
in
content
selection,
we
have
a
bug
if
you
get
well,
if
you
already
have
one
camera
and
you're
going
to
pick
a
different
camera,
and
then
you
you
hit
disallow,
you
might
accidentally
now,
you
know
removed
permission
so
this
the
language
that
I
proposed
him
on
these
slides
that
you
know
you
should
probably
have
a
benign
cancel
button
out
of
this,
because
the
semantic
context
is
like
different
you're.
A
A
C
F
F
F
Chrome,
yes,
so
this
would
provide
the
possibility
for
the
spec
would
allow
a
browser
vendor
to
implement
that
right
now,
the
spec
does
not
allow
the
browser
vendor
to
do
that
because
of
the
way,
unfortunately,
getusermedia
has
been,
and
it's
actually
not
even
specified,
but
how
it's
been
implemented
in
a
way.
That's
not
web
compatible.
If
you
were
to
do
that,
my.
C
E
C
J
B
F
F
The
way
it's
been
implemented
isn't
actually
spelled
out
that
it's
kind
of
says
that
assume
that
if
for
a
track,
that
already
is
live
assume
it
already
had
permission,
but
it
doesn't
say
anything
about
what,
if
the
application
constraints
don't
narrow
down
to
one,
it
doesn't
say
that
you
must
pick
that
one
again
as
user
agent.
We
just
happen
to
do
that
because
that's
what
people
expected
on
the
web
and
it
was
to
avoid
breaking
your
sites,
but
arguably.
E
A
F
D
I
D
F
F
A
A
It
turns
out
that
they
get
some
problems
when
there
are
too
many
of
them.
So
if
you
fire,
if
you
have
more
than
14,
you
need
something
called
2
likes
numbers
to
enumerate
them,
and
it
turns
out
that
some
partials
have
problems
related
to
bad
numbers
and
one
of
those
being
yeah,
chrome,
71,
which
is
still
1%
of
the
web,
and
so.
A
So
we
can
do
something
like
set
codec
preferences
and
said
that
controls
what
gets
offered
or
accepted
in
them
and
an
offer
announcer
exchange,
and
then
we
could
once
we
have
negotiated
support
for
something.
So
as
we
know,
they
know
that
the
other
party
will
not
die
horribly.
If
we
send
it,
you
can
add
a
control
for
the
center
for
saying
yes
use
this
or
don't
use
this.
A
B
A
comment
for
me:
Harold
I,
think
it's
overall
I
think
your
proposals,
a
good
idea.
The
only
thing
I
will
say
is
having
worked
on
an
implementation
of
this.
It
is
quite
tricky
to
validate
the
header
extension
information.
As
an
example,
there
may
be
some
extensions.
You
shouldn't
be
able
to
remove
like
the
mid
header
extension,
so
that
I
think
is
the
one
thing
we
need
to
work
on
a
little
bit
more
as
to
understand
exactly
what
the
validation
steps
are,
but
in
general
I
think
your
proposal
makes
sense
to
me
at
least
yeah.
C
K
A
A
B
B
A
B
I
mean
it's
an
example:
we're
likely
to
have
both
frame
frame,
marking
and
a
new
descriptor
format,
which
does
some
of
the
same
things
both
in
there
at
the
same
time,
and
you
probably
don't
want
to
do,
negotiate
both
of
them.
So
I
kind
of
think
this
is
going
to
be.
This
is
going
to
be
needed
or
even
more
chaos
could
break
out.