►
From YouTube: SES-mtg: sep 16 title soon
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
Loud
awesome
welcome
everybody
as
foretold
in
the
prophecy.
I
do
have
a
slide
deck
this
time,
so
without
further
ado
is
there
anything
we
wish
to
discuss
before
I
launch
into
this
presentation
about
the
status
of
the
sess
proposals.
B
C
Proto,
the
thunder
proto,
yes,
which,
which
committee
I
actually
had
had
not
been
able
to
take
the
time
to
look
at
before
this
meeting.
A
I've
noted
it
in
the
minutes
that
we
will
revisit
that
topic
when,
when
we're
prepared
to
discuss
it,
sound
good,
yep
I'll,
I
yeah-
I
will
go
so
far
as
to
put
that
on
the
agenda
for
to
next
week's
meeting,
sound
good,
yep,
all
right
cool,
I'm
going
to
share.
C
A
question
are
we
going
to
have
this
meeting
next
week?
It
is
overlapping
days
wise
with
the
tc39.
On
the
other
hand,
in
most
of
our
time
zones
tc39
is
not
now.
D
C
Never
have
it,
we
never
have
it
during
tc39
week.
I
I
think
we
should
continue
to
not
have
it
during
tc39
a
week.
There's
enough
meeting
and
discussing
these
topics
during
from
tc39
itself.
A
I
agree
procedure
from
chip,
so
we
will
cancel
next
week.
B
Cool
all
right
that
day
is
a
we
have
time
today,
maybe
at
the
end
of
the
meeting
we
can
talk
about
proto
because
it
will
be
discussed
in
next
week.
Plenary.
A
Okay,
well,
let's
time
box
it
now.
Actually,
if,
if
there's
an
urgency
on
it,
because
this
presentation
can
what?
Let's
do
you
think
that
you
need
10
20
minutes.
B
This
conversation
is
about
moving
things
out
of
annex
b,
and
I
think
marx
has
been
the
champion
of
that
for
quite
some
time
and
one
of
the
things
that
pops,
during
those
conversations
and
pull
requests,
was
the
underscore
underscore
proto
versus
other
things
like
underscore
underscore,
define
getter
and
define
you
get
the
fine
get
get
the
fine
set
and
so
on,
and
I'm
trying
to
make
the
case
that
underscore
underscore
proto
is
actually
very
important
capability
of
the
of
the
language
in
order
to
provide
full
virtualization
of
a
realm.
B
And
my
assumption
here
is
that,
if
you
don't
have
underscore
underscore
proto,
that
means
that
you
are
not
going
to
be
able
to
deny
the
undeniables
intrinsics,
because
you
don't
have
a
way
to
tell
the
engine
that,
when
producing
an
object
from
syntax,
the
proto
of
that
object
is
going
to
be
something
else.
Not
the
default.
Provide
undeniable
intrinsic.
That's
my
assumption.
I'm
sorry.
C
When
you
say
syntax,
I
just
there's
two
different
under
protos
in
the
spec
one
is
the
accessor
property
on
object,
prototype
and
the
other
one
is
the
special
syntax
and
object
literals,
which
one
are
you
talking
about.
The.
C
Oh
okay,
okay,
that's!
Okay!
Now
I
understand
yeah
I've
been
confused
this
whole
time.
I
thought
you
were
talking
about
the
other
one,
the
syntax,
the
the
special
literal
syntax
is
in
nxt.
C
C
C
B
So
if,
if
you
cannot
provide
you
on-
and
this
is
my
understanding-
I
might
be
incorrect
if
you
cannot
provide
the
underscore
underscore
protocol
getter
special
getter
in
the
object
prototype
that
when,
when
called
it,
would
try
to
replace
the
actual
object
with
something
else
from
a
undeniable
intrinsics
to
something
else.
If
you
cannot,
if
you
don't
have
that
hook,
we
will
not
be
able
to
provide
a
full
virtualization
of
all
the
undeniable
intrinsics.
And
let
me
let
me
maybe
that's
the
wrong
way
to
to
to
say
this.
B
B
Let
me
see
okay,
so
a
simple
one
would
be.
If
I
replace
array
dot
prototype,
I
replace
it
with
my
own
thing:
okay,
the
entire
object.
I
replace
the
entire
object
and
so
on,
and
I
replace
all
the
pieces
of
it.
In
the
case
of
the
membrane,
we
might
be
able
to
provide
a
proxy
of
the
outer
array
prototype.
B
That's
the
case.
If
we
do
so,
how
can
we
guarantee
that
when
you
do
square
brack,
a
square
bracket
square
bracket
to
produce
an
object,
and
you
do
a
something
with
that
object.
B
This
goes
back
to
the
conversation
that
we
have
a
few
weeks
ago
about
the
idea
of
denied
access
to
any
intrinsic
from
a
realm
and
instead
provide
a
full
virtualized
set
of
proxies
that
provides
all
the
functionality
of
the
language.
B
C
C
And
the
assumption
is
that
the
code,
the
local
code,
is
starting
from
open
square
bracket
close
square
bracket
and
if,
if
they
so
open,
the
square
back
a
closed
square
bracket,
no
matter
what
you
do
with
thunder,
proto
open
square
bracket
closer
bracket
will
create
an
array
object
that
does
inherit
from
the
local
array
prototype
that
you're
trying
to
deny
access
to
and
what
you're
trying
to
do
is
prevent
a
faithful
walking
of
the
prototype
chain.
C
You
want
to
take
any
attempt
to
walk
the
prototype
chain
and
misdirect
it
to
to
walk
across
the
membrane
into
the
other
array.
Prototype.
B
C
C
No,
what
what
are
the
the
the
situations
where
the
engine
is
walking
the
prototype
chain?
It
does
not
do
it
by
invoking
the
proto-accessor
you
can.
You
can
see
that
because
you
can
remove
the
prototype
accessor
completely
and
all
of
the
inheritance
properties
that,
where
the
engine
walks,
the
prototype
chain
will
still
work.
C
B
Right
well,
among
the
assumption
that
the
that
it
works,
if
you
remove
it
and
it
works
before
we
add
it,
but
if
you
have
it
and
you
customize
it,
you
provide
a
hook
for
the
engine
to
no
okay.
So
then
you
know,
then
then
this
is
not
a
problem
like
it's
not
going
to
provide
what
we
thought
it
was
going
to
provide
initially,
okay,
yeah.
C
That
the
engine
just
goes
directly
to
the
internal
to
the
internal
walking
function
and
does
not
consult
the
accessor
property.
A
Wrong
one
don't
know
how
it
missed
that:
how
about
this
time
are
you
seeing
a
presentation
or
a
calendar?
I'd
say
the
same.
A
A
All
right
cool
all
right,
so
the
purpose
of
this,
this
presentation
is
for
us
to
sync
up
on
the
various
the
statuses
of
the
various
proposals,
implementations
of
some
cess
relevant
specifications.
A
We
have
some
eventually
considered
to
be
consistent
truths
about
says
the
specification
proposals
for
tc39
the
xs
implementation,
the
shim
implementation,
to
the
extent
that
it's
possible
for
it
to
be
consistent
and
the
documentation
for
cess,
which
currently
reflects
the
old
reality,
the
pardon,
the
pre-compartment
reality
and
then,
of
course,
my
aspirations.
A
As
for
for
all
of
these,
based
off
of
the
the
the
requirements
that
that
I've
been
fed
for
making
progress
with
agorik,
and
so
just
to
recap,
the
the
we're
we're
planning
to
reframe
the
cess
proposal
as
an
umbrella.
It
is
currently
the
sas
proposal
as
as
written
today
is
a
proposal
for
realms
and
with
that
our
understanding
of
cess
has
evolved.
Since
then,
it's
now
broken
down
into
some
much
more
constituent
proposals
that
we
have
yet
to
write
apart
from
realm.
A
Realm
is
realm
is
in
the
realms
in
the
bag,
but
we
need
to
write
a
proposal
for
lockdown
and
harden,
and
the
proposal
that
bradley
has
started
for
compartment
is
still
a
sketch,
and
we
have
learned
through
conversations
here
and
and
abroad
that
the
compartment
proposal
needs
to
become
layered,
because
it
has
lots
of
different
facets
that
that
are
that
are
that
are
good
checkpoints
toward
toward
getting
into
the
specification
in
particular,
pairing
out
host
virtualization
as
a
topic
to
revisit
later,
as
well
as
just
layering,
the
the
evaluator
and
the
static
module
loader
and
the
dynamic
module
loader,
and
even
the
dynamic
module
loader
could
conceivably
broke
and
be
broken
into
two
layers.
A
So
this
is
a
slide
that
brian
werner
put
together
for
us
to
sync
up
with
figma
last
week
and
the
the
the
idea
of
this
is
that
the
the
proposals
as
they
stand
today
reflect
reality
where
the
security
boundary
that
we're
talking
about
is
the
border
guard
between
realms
and
the
compartment
specification.
A
Reacting
to
reacting
to
the
the
difficulty
of
protecting
integrity
at
the
border
guard
layer
has
moved
to
an
approach
where
we
have
a
powerful
start
compartment.
That
is
in
the
same
realm
as
the
confined
compartments.
A
So
this
this
implies
two
additional
two
or
two
or
three
additional
specifications,
one
for
one
for
the
compartment
for
the
confinement
purposes
and
one
for
lockdown
and
how
it
how
it
how
it
changes
the
the
the
start
compartment
among
other
things.
A
A
A
The
sketch
for
the
compartments
api
into
spec,
ish
and
then
breaking
up
the
compartment
proposal
into
layers
for
evaluation,
static
modules
and
module,
loader
and
and
evidence
suggests
that
if
we,
if
we
get
compartments
as
a
beachhead
in
the
specification,
then
we
can
begin
to
discuss
how
to
thread
host
virtualization
hooks
through
realms
and
compartments
on
a
piecemeal
basis
to
make
them
more
difficult
to
dismiss
as
a
block.
A
A
It
is
about
creating
a
circle
around
a
a
a
set
of
modules
typical,
and
there
are
two
there
are
many
ways
of
looking
at
that
and
it
can
be
used,
regardless
of
whether
it's
being
used
as
a
security
container
and
then
lockdown
lockdown
replaces
that
compartment
constructor
in
the
same
way
that
it
tames
other
powerful
evaluators
in
the
environment
to
make
it
into
a
security
container
or
suitable
suitable
for
for
containment
in
general
and
and
then
it
goes
ahead
and
erases
the
unallowed
intrinsics
in
this
in
child
compartments
and
hardens
the
intrinsics
in
both
the
start
and
child
compartments.
A
So
this
leaves
open
a
question
that
we've
been
struggling
with.
We
know
that
we
have
a
story
about
shims
and
the
idea
is
that
we
will
have
well.
We
will
come
up
with
some.
A
Some
story
that
would
allow
us
to
have
shims
participate
in
the
lockdown
process
and
we've
begun
mark
has,
in
particular,
begun
to
factor
lockdown
into
two
layers:
repairs
layer
which
needs
to
happen
before
shims,
get
a
chance
to
modify
the
intrinsics
and
and
then
a
lockdown
which
does
the
hardening
and
and
visits
all
of
the
intrinsics
and,
of
course,
replaces
the
compartment
constructor,
the
among
others.
I
think
that
might
actually
be
in
the
repair
phase.
A
In
any
case,
in
between
repair
and
running
your
vetted
shims,
there
needs
to
be
an
opportunity
for
shims
to
inform
lockdown
that
they
are
adding
new
intrinsics
or
modifying
existing
intrinsics
in
a
way
that
it
have
those
things.
Those
things
that
it
is
adding
to
the
environment
should
not
be
erased,
and
currently
these
this
object.
A
This
data
structure
for
the
intrinsics
is
a
private
api
within
lockdown
and
implemented
within
the
shim,
but
it
would
need
to
become
public
in
order
for
shims
to
participate,
which
means
growing
the
specification
for
lockdown
to
include
the
schema
for
the
intrinsics
and
the
allow
lists
for
what
not
for
what
lockdown
should
not
erase
from
the
start
compartment.
A
A
I
I
might
my
thought
on
this-
is
that
this
presentation
should
be
a
long
sequence
of
discussion
topics
and
if
it
runs
over
it's
fine,
we
should
just
let's
talk
now.
B
I
think
a
couple
of
notes
we
have.
We
have
good
success
in
the
past
when
trying
to
push
for
proposals
that
are
linked
to
other
proposals
and
depends
on
the
proposal
and
so
on.
So
the
first
question
would
be:
is
this
repair
and
lockdown
functionality,
something
that
could
be
used
without
a
compartment
without
a
compartment
in
general?
Can
we
use
this
with
a
realm?
Can
we
use
this
with
an
iframe?
Can
we
use
this
with
a
a
context
created
via
vm
module
in
node?
B
A
A
Yeah,
the
the
the
pitch
for
this
feature
is
that
this
is
a
defense
against
prototype
pollution
and
it
correct
me
if
I'm
wrong
mark,
but
I
think
that
it
is
useful
to
some
extent
without
introducing
a
new
compartment
evaluator.
But
it's
that
that
extent
is
is
limited.
C
That
that
is
correct.
It's
it's!
If
you
don't,
if,
if
you
don't,
if
there
is
no
compartment
instructor
and
this
repair,
shim
and
lockdown
mechanism
does
not
introduce
a
compartment
constructor,
what
it's
still
done
is.
It
is
still
a
repaired,
the
intrinsics
so
that
you
don't
have
capability
of
object,
capability
violations
among
the
intrinsics
and
it's
hardened
all
the
intrinsics,
and
it's
done
it
after
running
the
vehicle.
It's
done,
the
hardening
after
running
the
vetted
shims.
C
So
from
a
software
engineering,
robustness,
point
of
view,
that's
not
a
security
point
of
view,
you're
in
a
much
more
robust
system
for
programming
and
in
particular
you're
in
a
you're
in
a
situation
where,
if
something
is
buggy
in
a
way
that
that
just
sort
of
thrashes
and
causes
a
lot
of
non-local
damage
by
accidentally
modifying
objects,
it's
not
supposed
to
modify
you're
much
more
likely
to
catch
those
bugs
because
they'll
be
modifying
on
properties
that
are
frozen
and
also,
of
course,
the
repairs
will
have
also
removed
some
non-local
causality.
C
B
Okay,
so
you
said
that
the
repair
runs
before
you
execute
any
shin
poly
fill.
B
Is
it
then
repair
something
that
you
could
also
have
as
a
kind
of
a
configuration
when
you
create
a
new,
a
new
environment,
I'm
trying
to
think
about
the
ideas
of
providing
something
that
could
work
well
with
iframes
and
realms
and
so
on,
but
that
also
has
a
reflective
or
a
a
a
way
to
do
it
manually
if
you
want
to,
by
calling
a
method
on
a
particular
global
object,
or
something
like
that
without
having
to
it's
hard
for
me
to
understand
or
to
articulate
why
repair
will
have
to
call
before
you
do
anything
else
and-
and
if
that's
the
case,
then
why
why
it's
not
part
of
the
creation
of
the
environment
process
that
you
specify
that
you
want
to
to
be
born
into
that
estate
rather
than
be
set
into
that
state,
because
then
it's
very
difficult
to
assess
what
changes
before
you
call
repair.
C
So
so
so
one
of
the
one
of
the
motivations
here
is
that
in
a
in
the
excess
or
tc
53
configuration
the
you're
you're,
not
running
in
a
full
javascript
engine,
you're
running
in
in
a
cess
engine
effectively,
so
you're
already
starting
out
repaired.
There's
no
unrepaired
state
to
start
with
so
repairs,
but
you'd
still
be
running
the
shim
during
the
build
time
phase,
which
is
still
a
a
phase
with
the
repairs.
C
But
it's
not
until
after
all
of
the
build
time,
customization
runs
that
you
do
the
the
the
hardening
in
you
know,
preparation
for
cutting
a
rom.
So
so
we
certainly
want
to
support
configurations
like
that
where
there
simply
is
no
pre-repaired
javascript,
because
there's
just
no
reason
to
build
all
of
that
mechanism
that
that
repair
would
remove.
C
That's
that's
pretty
much.
The
main
danger
is
that,
if
you
run
before
repair,
then
you
can
capture
things
that
repair
would
remove.
The
most
obvious
example
of
that
is
the
evaluators
you
could
capture
the
original
eval
function.
You
can
capture
the
original
function,
constructor
you
could
capture
on
v8,
for
example,
you
can
capture
the
original
error
constructor
that
has
all
sorts
of
bizarre
reflective
things
for
accessing
the
stack.
C
C
Yeah
yeah
we're
not
so
we're,
so
we're
we're
not
precluding
that.
I
mean
this
this.
This
design
is
compatible
with
that.
If
you're,
if
you're,
if
repair,
is
something
that
you
do
because
you're
starting
off
in
an
unrepaired
environment,
then
you
absolutely
there's
nothing
preventing
you
from
running
code
before
repair
and
this.
What
we're?
What
we
would
be
proposing
would
leave
all
of
that
well
defined
about
what
happens.
If
you
do
that,
okay,.
B
C
So
so
the
lockdown
mechanism,
before
it
hardens
the
intrinsics.
It
goes
through
that
we
have
the
the
internal
api
that
chris
was
referring
to
is
our
white
list.
So
we
have
a
white
list
of
all
of
the
properties
of
on
the
of
the
primordials
that
are
supposed
to
still
be
there
after
lockdown.
C
So
before
lockdown
freezes
things,
it
goes
through
all
the
primordials
and
it
removes
all
properties
it
finds
that
are
not
on
the
white
list.
If
a
shim
adds
properties,
then
in
order
for
lockdown
not
to
remove
the
properties
of
the
shem
added,
the
shim
has
to
make
it
clear
that
those
extra
properties
are
intentional.
C
Has
to
make
that
clear
somehow
so
that
at
the
point
you
run,
lockdown
lockdown
can
consider
those
extra
properties
to
now
be
part
of
the
augmented
white
list.
The
other
element
of
the
there's
there's
so
there's
there's
one
element
of
the
light
list.
Is
this
one,
which
is
what
properties
exist
and
also
how
they're
wired
together
the
the
white
list
actually
tells
you
a
lot
about
the
topology
by
which
they
point
at
each
other.
C
The
the
other
white
list
that
we
have,
which
is
right
now
in
a
separate
file
called
enablements,
is
the
very
small
white
list
of
property
of
data
properties
holding
that
we're
replacing
with
access
to
properties
in
order
to
work
around
the
override
mistake,
we're
finding
there's.
You
know
something
on
the
order
of
a
dozen
or
two
dozen
properties
that
experience
is
shown.
C
If
you
fix
those
to
to
work
around
the
override
mistake,
you're
pretty
much
done,
we've
been
expanding
that
on
an
as
needed
basis
as
we
encounter
problems
and
at
this
point
we're
expanding
that
white
list
at
a
glacial
pace.
C
B
So
we
repaired
then,
and
then
we
locked
down
I'm
still
confused
or
not
confused,
but
I
still
not
clear
about
what
this
white
listing
or
allow
listing
is
doing.
B
C
The
problem
is
that
engines
historically,
as
well
as
hosts,
have
added
crappy
new
properties
to
intrinsics
that
if
we
encounter
a
property
that
we've
never
heard
of
before,
we
want
to
make
sure
to
remove
it
before
hardening
the
intrinsics,
because,
if
we've
never
heard
of
it
before,
we
have
no
basis
for
thinking
that
it
doesn't
destroy
everything.
We're
trying
to
achieve,
and
in
fact
that
has
saved
us
several
times
before.
B
Do
you
have
any
example
of
one
of
those
crappy
things
that
affects
or
give
you
extra
power
there.
C
C
C
So,
even
though
it's
not
a
example
of
something
that
this
mechanism
actually
does
address,
it
comes
to
mind
because
it's
just
something
that
a
host
inadvertently
added
without
realizing
the
damage
it
was
doing
that
and
we
certainly
have
I'll,
have
to
find
some
examples,
but
we
certainly
have
encountered
that
on
the
primordials
as
well
that
something
that
that
somebody
added
something
crappy,
we
removed
it
and
we
saved
ourselves.
Oh
a
great
example
is
the
era
constructor.
The
v8
error.
C
Constructor
has
all
of
this
stuff
for
for
intervening
on
stack
reflection
and
oh,
oh,
oh
yeah,
perfect
one
of
the
things
in
the
error.
Constructor
is
that
the
behavior
of.
C
The
v8
will
actually
add
the
stack
property
to
it
anyway,
even
though
it's
frozen,
probably
because
the
the
the
mechanism
is
taking
some
shortcut
through
the
virtual
machine,
that
was,
you
know
that
was
not
carefully
audited
for
preserving
the
object
in
variance.
C
That's
just
you
know,
that's
that's
just
a
a
crappy
bug
that
v8
introduced,
I
filed
a
buggy
against
that
they
haven't
fixed
it
yet,
but
the
weightless
mechanism
ensures
that
if
something
like
that
were
were
there
and
we
didn't
know
about
it,
it
would
be
removed
if
we
didn't,
if
we
weren't
repairing
the
error
constructor,
our
whitelist
would
remove
capture
stack
trace
from
the
error
constructor
anyway,.
B
B
More
more
like
a
political
problem,
also
it's
a
hassle
for
developers,
because
the
developers
don't
have
a
clue.
What's
going
on
the
engine
provides
certain
certain
capabilities.
They
have
code
that
is
going
through
a
certain
path
that
is
not
doing
any
anything
harmful,
but
it's
just
using
some
of
these
features
that
are
provided
by
browsers
and
now
we're
removing
them.
C
No
that
I
I
disagree,
the
it
should
be
specified
by
262,
because
we're
trying
to
create
something
who's,
who's
whose
invariants
are
his
properties
in
general,
are
independent
of
the
house.
No.
B
C
Okay,
so
I
agree
that
there's
a
possible
political
problem
here
and
we've
certainly
divided
things
up
and
and
and
and
refactored
things
in
order
to
navigate
through
political
issues,
but
generally
we've
done
it
after
we've
actually
encountered
the
political
issues.
One
of
the
things
that
I
don't
want
to
do
is
reduce
the
quality
of
the
technical
proposal
in
anticipation
of
political
issues.
That
might
not
be
there.
D
If
I
could
just
share
that
briefly,
sorry
karate
just
very
much
to
your
point
on
node.js
that
you
end
up
doing
host
specific
stuff.
D
Yes,
we
probably
haven't
got
it
right
in
in
node.js
right
now,
but
the
model
does
end
up
the
the
sort
of
well.
The
model
that
we
have
in
node.js
right
now
is
we
have
some
kind
of
attenuation
followed
by
some
kind
of
lockdown
seems
like
that's
likely
the
model
that
that
kind
of
sticks
where,
where
loaders
can
control
the
attenuation
phase
and
the
the
sort
of
lockdown
happens
with
some
host
integration.
D
But
yeah,
I
I
see
that
there's
like
an
information
problem
like
I
guess
practically
when
we
discuss
this.
We
always
imagine
that
we
want
to
just
hand
over
to
to
loader
users.
We
don't
know
what
they're
going
to
do
expecting
them
to
pass
back
a
nice
object
where
they
carefully
tell
us
everything.
They
did.
D
I'm
just
trying
to
understand
the
ergonomics
of
that
as
well
in
terms
of
what
we
would
want
to
implement,
and
you
know
if
it's
just
an
array
of
like
member
expressions
or
is
it
you
know
a
more
sort
of
fine
grain,
because
the
concern
there
is,
if
you're
expecting
people
to
to
construct
this,
then
people
might
just
not
do
it,
and
then
you
end
up
not
being
able
to
enable
freezing
at
all
for
loads
that
have
these
properties
yeah.
B
That's
that's!
That's
thanks
a
lot
guy
for
for
bringing
this
up.
This
is
definitely
an
issue.
Yes,
like
it's
just
it's
just
difficult
for
people
that
don't
know
much
about.
What's
going
on,
to
decide
what
to
do
and
what
to
put
into
that
list
and
how
difficult
is
to
build
a
list
and
what
is
the
outcome
or
what
is
the
benefit
of
versus
just
saying
harder
than
everything
that
you
know
in
terms
of
you
know
the
objects.
Those
are
the
intrinsics
that
you
know.
B
C
So
the
the
the
reason
we
call
these
vetted
shims
is
that
you're
running
these
before
before
hardening,
and
that
means
that
everything
that
happens
afterwards
is
completely
vulnerable
to
these
shims.
C
Right
now
provides
a
diagnostic
shows
you
when
it's
when
it's
removing,
I
mean
just
you
know,
does
a
console
log
of
the
message
when
it
removes
a
property
that
it
was
not
expecting
and
the
the
so
configuring
a
vetted
shim
might
take
some
existing
shim
and
just
add,
you
know,
add
on
the
side,
this
declaration
of
what
properties
are
supposed
to
be
added,
and
you
can
use
this
diagnostic
to
figure
out
what
those
pro
well,
you
know
what
the
candidate
properties
should
be,
but
if
you
just
blindly
list
the
properties
that
it
adds
without
thinking
about
it,
then
you
know,
then
you
voided,
the
warranty.
B
So
among
the
question
for
you
on
that
mark,
so
normally
the
way
we
look
at
polyfills
is
we
say
well
if
the
polyfill
is
adding
a
new
feature
that
is
based
on
existing
functionality
that
is
provided
by
the
the
engine.
Let
me
find
a
good
example
for
that.
I
think,
like
think
about
object
or
assign,
or
or
some
other
polyfill
which
is
using
all
or
or
some
other
or
a
feature
that
use
define
properties
and
get
on
properties
and
so
on
to
build
the
properties
that
you
want.
B
If,
if
the
underlying
pieces
are
already
hardened
and
they
are
already
well
defined
and
they
have
all
the
all
the
capabilities
that
you
want,
it
doesn't
give
you
extra
power
or
anything.
Anything
that
you
build
after
repair
seems
to
be
fine
from
the
perspective
of
well
you're,
not
going
to
access
any
of
these
evaluators
and
any
of
these
sort
of
things
that
might
give
you
extra
power
you're,
just
building
more
features.
B
On
top
of
the
features
that
you
already
have,
I
I
wonder:
what
kind
of
things
can
you
do
that
really
damage
the
the
program
in
a
significant
way
versus
just
hardening
everything
that
is
on
those
prototypes.
C
Okay,
so
so
the
the
shared
intrinsics
now
I'm
going
to
bring
in
compartments
under
the
the
you
know,
part
of
the
purpose
of
all
of
this.
In
fact,
the
motivating
purpose
of
all
this
is
to
set
things
up
so
that
you
actually
have
a
good
security,
preserving
system
of
shared
intrinsics
among
mutually
suspicious
compartments.
C
In
order
to
do
that,
the
shared
intrinsics
are
supposed
to
be
completely
without
mutable
state
or
I
o
abilities.
The
vetted
shims
are
running
in
the
start
compartment
where
the
start
compartment
has
host
powers,
it
has
the
original
date
dot.
Now
it
has,
you
know
all
sorts
of
other.
You
know
all
the
original
host
objects
that
one
expects
in
the
start,
compartment
remain
in
the
start,
compartment
after
repair
we're
not
trying
to
deny
power
to
the
start
compartment.
C
But
what
that
means
is
that
a
shim
could
easily
add
into
the
primordials,
not
just
mutable
state,
that
creates
a
communications
channel
or
a
capability
leak
between
otherwise
isolated
compartments.
But
it
can
actually
add
in
I
o
abilities,
we're
out
and
so
we're
allowing
that
to
happen.
C
D
I
I
think
that
that
actually
sorry,
if
I
might
just
add
just
back
to
my
previous
point-
that
really
clarifies
the
model
for
me
in
terms
of
what
node.js
might
implement,
because
I
guess,
if
we
interleave,
for
you,
know
this-
the
single
frozen,
intrinsic
concept
with
with
the
repair
in
a
lockdown
running
the
attenuation
in
between
and
then
in
policy,
allow
the
global
definitions
to
be
defined
as
a
sort
of
out
of
band,
and
then
you
can
have
automatic
generation
of
that.
So
it's
not
something!
D
That's
that's
pushed
out
to
the
sort
of
loaded
you
create
authors
or
or
people
who
are
writing
those
continuations.
In
the
first
place
it
could
potentially
just
be
a
final
end
step
to
to
set
up
that
policy
that
that
that
sort
of
sets
that
white
list
that
that
sounds
like
it
does
get
through
any
of
the
usability
issues
that
I
would
imagine
at
least
for
node.
A
Yeah,
I
think
that
it's
important
to
note
that
this
api's
intended
audience
is
people
who
are
who
are
trying
to
a
very,
very
narrow
list
of
people.
People
who
are
using
the
people
using
this
api
are
using
it
either
because
they
are
preparing
an
environment
that
has
security
properties
for
their
application
or
they're
participating
in
because
they
are
providing
shims
that
to
other
people
who
are
creating
secure
environments,
and
so
security
is
foremost
on
their
mind.
A
In
both
cases,
the
the
exceptions
are
the
people
who
are
trying
to
make
an
existing
application
work
with
existing
shims,
who
would
have
to
to
carefully
vet
those
gems.
Thus,
the
name
and
in
that
process
of
reviewing
them
make
express
decisions
about
what
should
be
permitted
in
in
the
applications
locked
down
environment.
A
One
example
of
that
would
be
suppose
that
you're
using
a
color
shim
that
adds
a
red
or
a
red
method
to
the
string
prototype
all
right.
You,
you
have
two
options
here.
It
is
assuming
this
is
deep
in
your
transitive
dependencies
and
it
would
take
forever
to
get
all
of
your
transitive
dependencies
to
agree
to
removing
that
behavior
from
from
from
their
packages.
A
An
alternative
is
is,
if
you
deem
that
those
methods
are
indeed
harmless.
You
could
go
into
your
applications,
process
of
preparing
its
environment
and
introduce
a
layer
that
says
hey.
All
of
these
methods
will
be
permitted
to
exist
after
lockdown,
and
I
will
run
this
run.
This
exact
version
of
that
package
before
running
any
of
the
application
code.
B
B
You
figure
that
you
need
that
method
for
whatever
reason,
so
you
go
and
enable
it
the
other
one
is
well
is
enabled,
but
it
tells
you
that
is
seeing
something
weird
that
if
you
don't
want
it,
you
go
and
run
the
code
to
remove
it.
You
remove
it
because
you
don't
want
it,
and
so
I
I
I
feel
that
the
outcome
of
it
is
the
same.
B
It's
just
how
a
developer
will
confirm
this
situation
and
and
and
move
on,
and
it
feels
to
me
that
if
you
really
really
care
about
it,
you
you
look
at
the
locks
and
say:
oh
this
thing
is
it's
a
thing
that
the
lockdown
process
doesn't
know
about.
It
is
complaining
about
it,
saying
that
it's
there
it's
being
locked
down,
but
it's
there.
So
is
it
a
thing
that
I
want
to
remove,
because
I
feel
that
this
is
incorrect.
B
I
think
it's
so
such
a
tiny
piece
that
flipping
the
switch
and
saying
we
we're
hot
and
everything,
and
then,
if
we
tell
you
when
we
encounter
something
weird
and
you
can
audit
that
if
you
want-
and
maybe
the
lockdown
can
have
an
option,
that
you
can
be
more
specific
about
it
and
you
can
provide
an
option
to
remove
anything
that
is
not
there,
but
by
default
it
does
the
work
of
hardening
everything.
That
kind
of
thing
we
could
explore,
like
the
ergonomics
of
it.
C
C
B
Yeah
we
have
some
prior
art
on
that.
Like
the
we
discussed
in
the
past
the
attack
shadow
that
requires
the
mode
of
operation,
it
doesn't
have
a
default
value.
You
must
provide
it.
We
could
do
that.
We
can
explore
the
default
behavior
and
those
are
the
things
that
we
can.
We
can
get
into
it
later
on,
but
I
I
feel
if
we
go
and
present
this
in
we're
going
to
remove
everything
and
that
you
you
have
to
provide
the
list
and
so
on,
it's
just
going
we're
going
to
get
some.
C
Okay,
so
here's
so
as
you
as
you
were
saying,
as
you
were
saying
that
another
default
occurred
to
me,
that's
actually
even
safer
than
what
we're
talking
about,
which
is
before
running
the
vetted
shims.
You
know
during
the
initial
repair
phase,
we
first
run
through
the
pristine
white
list,
the
unaugmented
whitelist,
and
remove
everything.
That's
not
on
the
whitelist.
C
Before
we
run
the
repairs,
then
we
run
the
repairs
and
if
the
repairs
had
added
or
changed
anything
without
a
separate
declaration
that
have
intended
to
do
it
on
purpose,
then
lockdown
fails
rather
than
removing
things.
It
actually
says.
Look
the
vetted
shims
did
something
that
they
did
not
declare
they
were
doing
on
purpose.
Therefore,
we
have
to
assume
that
the
that
the
shim
was
not
properly
vetted
and
therefore
we
fail
to
lock
down.
We
actually
fail
to
to
construct
a
working
environment.
We
do
not
proceed
assuming
safety.
C
But
that's
right,
but
this
is
better
than
the
previous
one,
because
it
means
that
if
they
don't
provide
in
the
previous
the
previous
thing
we
were
suggesting
if
the
shim
adds
something
that
it
doesn't
declare.
C
B
C
That's
true,
if
you
never
lock
down,
none
of
this
means
anything
and
that's
actually
a
perfectly
reasonable
thing
to
do.
Which
means
you
basically
you're
just
using
the
repair
phase
to
change
your
environment
and
then
everything
is,
is
you
know,
then
all
of
your
code
becomes
to
be
in
the
post,
repair,
pre-lockdown
execution
mode,
in
which
case
the
fact
that
that
things
do
not
have
good
security
properties
is
consistent
with
the
fact
that
you
never
locked
down,
so
nothing
ever
claimed
to
be
providing
these
security
properties.
A
All
right:
well,
I
think
that
we've
reached
a
a
useful
and
novel
insight
about
the
design
of
this
api.
Thank
you,
karate
I'll
I'll.
I'd
do
a
round
on
that
as
well
and
and
maybe
come
up
with
a
new
proposal.
We
got.
You
know
a
few
slides
in.
If,
if
every
slide
is,
is
this?
A
I
think
that
it
is.
I
think
that
we
have
our
docket
for
the
year
worked
out,
which
is
actually
great.
A
C
Chris,
maybe
it
makes
sense
given,
given
that
kind
of
expansion
to
have
maybe
next
time
we
meet
do
one
where
you
go
all
the
way
from
beginning
to
end.
Without
the
discussion
just
like
we
get
a
sense
of
the
whole
thing
and
then
we
go
back
to
the
beginning
and
do
it
with
discussion.
A
It
sounds
great,
it
sounds
great
yeah,
so
that'll
be
the
plan
next
week.
We'll
do
a
cursory
review
of
all
of
the
topics
that
we
have
on
the
on
the
docket
and
then
and
then
go
through
them
again
and
probably
break
it
up
into
a
whole
bunch
of
conversations.
A
Yes,
next
time,
yeah
we're
a
little
bit
over
I'm
going
to
turn
off,
recording.