►
From YouTube: SES Meeting: Review SES core evaluator upgrade
Description
In this session, we review a change proposed by Aaron Davis that replaces the scope proxy leak in SES with a sloppy mode leak that affects functions declared in the global scope of a strict script evaluated by the SES shim.
A
Well,
the
CES
meeting
didn't
happen
so
we're
doing
this
instead,
which
is
actually
kind
of
appropriate
since
we're
actually
looking
at
sets
today,
Aaron
Davis
of
mask
has
produced
for
us
a
pull
request
that
would
re
replace
the
eight
magic
lines
with
four
wrist
blocks,
which
we're
currently
calling
the
four.
What.
B
A
Quadruple
backflip
or
the
four
backflips
of
the
apotheosis
I
Aaron
keeps
changing
The
Branding
for
this,
but
the
point
of
it
is
that
this
would
allow
us
to
eliminate
the
possibility
of
leaking
the.
What
we
currently
have
is
called
the
scope
proxy
and
thank
you
Matthew
for
showing
this.
This
is
the
heart
of
it.
We're
changing
the
eight
magic
lines
into,
however
many
Magic
lines.
This
is.
C
A
The
idea
is
that
by
taking
what
was
just
the
scope
proxy
and
then
creating
four
layers
out
of
it,
we
create
for
one
a
more
auditable
artifact,
where
each
of
these
individual
layers
can
be
evaluated
for
their
they're
they're,
isolated
purpose,
but
also,
most
importantly,
when
you
access
a
name,
a
free
variable
from
with
an
assess
program.
It
will
the
apartment,
when
you
access
a
free
name,
corresponding
to
a
function
and
then
call
that
function.
A
The
in
sloppy
mode,
which
we're
well
pardon
in
in
the
mode
of
execution
that
we
are
in
if
under
says
by
whatever
name.
It
is
that
the
the
rule
is
that
this
object
will
be
bound
to
whatever
object.
It
was
extracted
from
on
the
with
block.
Currently,
that's
the
scope
proxy.
So
we
leak
the
scope
proxy
with
this
change.
A
If
you
re,
if
you
get
a
free
variable
and
it
corresponds
to
a
property
of
the
global
object,
your
that
your
receiver
will
be
bound
to
the
global
object,
which
is
also
incorrect
in
terms
of
what
we
want,
which
would
be
a
high
fidelity
emulation
of
what
happens
inside
of
a
JavaScript
module.
That
is
to
say
undefined,
but
leaking.
The
global
object
is
less
risky,
albeit
not
less
insecure,
because
what
we
have
is
secure.
We
just
would
reveal
the
global
object
instead,
that
is
so
so.
A
So
the
way
that
it's
peeled
off
in
this
is
eval
scope
is
an
object
that
is
solely
responsible
for
allowing
the
unsafe
eval
to
pop
out
once
on
line
70
and
then
deny
it
thereafter,
and
then
the
global
lexicals
serve
as
either
the
lexical
environment
of
a
module
or
the
lexical
environment.
The
that
was
passed
into
the
the
compartment
Constructor
or
a
combination
of
the
two.
B
C
A
Yeah
Global
lexicals
is
doing
double
duty:
okay
and
the
scope.
Terminator
is
actually
one
of
two
different
things.
Now
this
is
the
only
proxy
and
it
is
the
proxy
that
will
only
be
reached
if
you
have
a
free
variable
that
isn't
doesn't
correspond
to
a
global
or
a
lexical
or
that
eval
once,
and
that
means
that,
in
this
implementation,
the
scope
Terminator
can
either
be
an
opaque
object.
A
That
just
refuses
to
give
you
anything
and
claims
to
have
anything
which,
basically,
which
which
effectively
masks
the
scope
from
anything
in
the
real
Global
this
and
can
be
shared
across
compartments
safely,
because
it
has
absolutely
no
State
whatsoever.
It's
just
a
it's
just
a
closed
door
or
if
you're
in
sloppy
globals
mode.
A
B
C
B
D
C
B
C
A
Yeah,
so
that
is,
there
are
two
things
on
that,
but
the
probably
the
most
important
one
is
that
that
is
a
separable
concern
from
this
PR
and
Aaron
experimented
with
doing
both
fixes
at
the
same
time
and
ran
into
complications
which
I'm
sure
we'll
get
to
hear
about
when
we
talk
okay.
So
he
chose
not
to
address
that
in
this
PR
and
we'll
see.
If
we,
if
we'll
see
if
the
text
is,
is
consistent
with
that.
C
D
All
right
so
well,
the
first
piece
of
code
I
ended
up
looking
at
is
the
eval
scope,
which
is
this
and
when
reading
this,
my
concern
was
that
the
one-time,
evil
properties
is
in
charge
of
deleting
from
eval
scope,
but
we
really
trust
the
color
of
creative
on
scope
to
add
the
one-time
properties
to
evil
scope.
Mm-Hmm.
D
C
C
A
Yeah,
that
is
good,
also
will
never
happen
if
this
by
design.
That
should
never
be
possible
right,
because
the
first
thing
that
happens
is
that
you
access
you
access,
eval
and
then
it
deletes
the
property.
And
then,
if
you
were
to
set
eval,
then
it
will
go
higher
up
the
chain.
The
and
I
believe
that
Aaron
was
kind
enough
to
add
tests
to
that
effect.
To
make
sure.
C
B
C
A
A
B
B
C
A
B
D
B
B
D
C
A
B
For
a
naive
interpreter,
I
I
believe
that
for
a
jit
system,
where
we
just
don't
know
what
weird
optimizations
it
might
be
doing
on
One
path
and
not
the
other,
it's
hard
to
know
that
we've
actually
allocated
enough
stack
in
the
one
case
to
cover
the
allocation
that
happens.
In
the
other
case,
it
might
be
that
they
optimize
the
first
one
away.
A
D
B
B
B
C
D
A
B
B
A
B
D
B
C
B
D
A
A
D
B
B
B
It
throws
if
it
fails
if
the
property
itself
continues
to
exist,
so
so
the
delete
succeeds
if,
following
the
delete,
the
properties,
whether
it's
absent,
because
it
was
deleted
or
it's
absent
because
it
wasn't
there
in
the
first
place,
the
elite
doesn't
care.
In
both
cases.
It's
a
success
and
if
the
property
is
Not
absent,
then
the
delete
has
failed
and
in
strict
strictly
will
then
throw
in
a
non-script
and
a
sloppy
delete
will
return
false
I.
D
B
D
A
C
C
A
C
D
B
C
A
D
D
C
C
D
Scope
Terminator,
so
here
is
the
first
change
like
notice
cup
Terminator
is
Christmas
mentioning
earlier.
It
can
be
either
a
shared
scope
Terminator
if
you're
in
strict
mode,
because
the
only
purpose
of
that
thing
is
to
just
deny
all
or
a
pair
compartments
scope.
Terminator
that
is
linked
to
the
global
object
of
the
compartment,
and
most
code
is
going
to
be
in
strict
globals
mode,
which
means
we
can
just
have
a
single
shared
scope,
Terminator
proxy.
That
denies
all
and
doesn't
leak
nothing.
D
B
B
D
A
D
A
So
so
it
would
a
valid
a
valid
alternative
to
this
would,
in
fact,
as
you
say,
Matthew
for
the
optimizer
to
have
two
I
either
have
two
optimizers
or
two
or
have
the
optimizer
have
two
Clauses
with
it,
one
for
extracting
properties
from
Global,
lexicals
and
one
for
extracting
properties
of
global
object.
The
difference
in
code
would
be
that
the
optimizer
generator
would
have
to
be
careful
to
make
sure
that
the
Lexile
lexicals
overshadow
the
global
object,
so
the
global
object
Optimizer
would
have
to
omit
any
that's
already
in
the
lexicals.
D
A
A
D
A
A
B
D
A
B
D
C
C
B
A
B
A
D
Yes,
so
the
constants
or
the
evaluator
is
generated
lazily
the
first
time.
Any
evaluation
is
done
in
the
compartment
for
function
and
eval
and
then
I
guess
for
evaluation.
When
there
are
new
Global
lexicals
for
some
modules,
the
evaluator
is
rebuilt
because
it's
a
different
set
of
global
lexicals
and
then
after
first
time,
it's
built
with
the
same
sets
of
basically
have
constant
the
same.
D
The
same
Global,
lexical
subjects,
I
think
it
is
never
rebuilt,
so
it's
cached.
So
the
idea
is,
you
can
build
your
compartments.
You
can
go
in
and
set
up
the
global
this
and
the
compartment
and
freeze
them
and
and
do
everything
there,
and
then
you
eval,
and
at
that
point
this
is
when
the
optimizer
is
built.
So
you
have
an
opportunity
to
have
an
Optimizer.
That
does
something,
but
if
you
go
in
and
modify
your
Global
after
that,
it
won't
take
advantage
of
the
optimizer
anymore.
Okay,.
B
D
D
C
C
A
We're
coming
up
on
time,
would
you
mind
wrapping
up
this
comment
and
and
submitting
a
partial
review
so
that
we
can
have
this
as
the
input
for
our
next
meeting?
Yes,
we'll
be
there
and
I
think
I
think
that
the
next
step
for
us
in
this
review
would
be
to
look
at
how
the
tests
have
changed
and
I.
Don't
recall
whether
Aaron
has
already
rebased
this
on
top
of
the
other
pull
requests
that
simply
adds
more
tests
that
pass.