►
From YouTube: SES Meeting: Compartments refresh
Description
Wherein we welcome Olaf of MetaMask’s Snaps team to discuss StaticModuleRecord security claims, and then review Kris’s refresh of the TC39 Compartment proposal diff.
A
B
Hi
welcome
everybody.
I'm
olaf,
I'm
an
engineer
at
mandamask
snubs,
so
currently,
snaps
are
run
as
a
immediately
invoked
function
inside
this
nes
environment.
What
we
do
is
we
inject
an
object
that
provides
a
way
to
register
apis
from
snaps
themselves.
We
call
them
our
pc
handlers.
What
we
wanna
do
is
we
wanna
move
to
a
model
where
the
snaps
themselves
export
functions
with
specific
names,
and
we
use
that
exported
module
as
an
api
that
we
talked
to.
B
A
Of
course
awesome
yeah
I
can.
I
can
feel
that
question.
It
depends
on
how
deep
we
need
to
go,
but
the
the.
So
we
have
this
proposal
for
compartments,
and
my
understanding
is
that
metamask
is
currently
only
using
compartments
for
their
evaluate
method.
Right,
no
wait,
not
you're,
not
even
necessarily
using
the
evaluate
method,
because
you
sometimes
run
in
a
no
eval
content.
Security
policy.
B
A
A
A
Let
me
reframe
the
question
that
in
in
what
I
think,
what
I
think
that
the
the
ask
is
yeah.
I
used
the
word.
What
your
request
is
to
you
that
you'd
like
to
use
the
s
shims
support
for
esm
modules,
so
that
you
can
take
advantage
of
module
namespace
objects
in
order
to
host
the
yeah,
which
is
very
similar
to
how
we're
using
it
at
agorik
and
how
we
intend
to
use
it
for
endo.
A
The
the
the
the
technical
thing
going
on
here
is
that
the
shim
is
an
emulation
of
what
we
wish
compartments
to
be
when
they're
added
as
a
language
feature
right,
which
is
to
say
that
a
lot
of
the
shape
of
the
compartment
api
is
dictated
not
by
what
is
the
easiest
thing
to
do
to
achieve
your
ends
in
javascript.
But
what
is
the
easiest
ends
to
emulate?
How
we
want
to
use
it
in
the
browser
someday
without
a
shim?
A
A
So
you
provide
the
fully
qualified
address
of
the
thing
you
want
to
run
and
then,
in
order
to
serve
that,
the
compartment
has
hooks
for
module
resolution,
which
is
to
say
how
to
take
an
import,
specifier
and
its
referrer
module
specifier
and
give
you
the
the
logical,
full
specifier
for
a
particular
import
in
in
some
modules
bindings,
which
is
synchronous,
followed
by.
How
do
you
get
a
module
descriptor
for
that
module
by
going
off
and
fetching
something
off
of
the
file
system
or
the
web?
How
do
you
treat
namespaces?
A
How
do
you
treat
the
namespaces
if
it's
on
the
web
or
for
coming
from
a
bundle
or
coming
from
some
other
source,
all
of
which
are
possible?
Because
it's
fully
it's
it's
a
it's
a
host?
It's
it's
a
host
hook
that
the
compartment
api
provides.
So
that
is
the
pure
version
of
the
story.
The
the
rea.
The
shim
reality
is
that
the
security
ben,
the
security
guarantees
of
the
session.
A
All
are
framed
in
terms
of
eval,
so
evaluate
is
the
basis
of
the
security
model
and
and
the
language
does
not
yet
provide
something
like
compartment.
That
would
you
allow
you
to
evaluate
module
sources,
so
we
emulate
that
by
using
the
static
module
record
package
to
do
a
source
to
source
transformation
from
esm
to
a
program
that
you
can
evaluate
in
the
compartment
and
the
compartment.
A
A
There
are
basically
two
different
ways:
different
sets
of
compromises
for
how
to
do
that,
one
of
which
is
you're
writing
a
program
in
development.
There's
no
round
trip
time
between
the
compartment,
that
is,
between
the
container,
that's
executing
and
the
file
system,
the
local
file
system.
So
in
that
case,
it's
practical
to
just
use
the
compartment
api
to
run
the
thing
off
of
a
file
system
and
do
all
of
the
exploration
of
all
of
the
module
graph
asynchronously.
Because
you
know
you
find
you
find
your
entry
point
module.
A
B
A
A
This
is
what
we
use
at
agorik.
So
there's
a
there's.
A
a
package
exported
from
endo
called
bundle
source
that
we
use
at
agorik
that
takes
an
entry
point
on
the
file
system
and
then
generates
an
archive
that
can
be
later
run
by
import
bundle.
Another
package
provided
by
by
agoric
and
then,
if
you
use
that,
then
you'll
be
able
to
pres,
then
you
will
certainly
be
able
to
benefit
from
everything
that
zb's
doing
right
now
to
add
common
js
support
as
well.
B
A
Be
no,
that's
not
actually
the
case.
Well,
it
is
part
of
the
story,
not
the
whole
story.
There
are
three
kinds
of
bundles
that
we
can
generate
with
bundle
source
that
one
of
which
is
called
get
exports
which
we
use
for
bootstrapping,
and
that's
not
what
you're
looking
for
the
get
exports
is
an
all
the
oldest
one
we
have
and
it
depends
on
roll
up
at
the
end
of
the
day.
So
it
wouldn't
put
you
in
a
position.
That's
any
different
than
what
you've
got
with
browser
with
preservify.
C
A
A
So
compartment
mapper
has
a
bundler
that
is
spiritually
analogous
to
wall
upper
brasserify
and
to
be
clear,
olaf.
This
is
not
something
that
would
satisfy
your
use
case.
I
don't
think
it
might.
I
don't
think
so.
We
use
it
for
what
we
call
bootstrapping,
which
is
to
say,
building
the
module
system
so
that
we
can
use
the
module
system
for
other
subsequent
message
for
other
subsequent
bundles
and
so
there's
a
in
order
to
deliver
the
module
system
to
our
our
container.
A
We
use
that
format
and
in
endo
we
have
a
partial
implementation
of
what
that
could
replace
roll
up.
For
that
purposes
it
is
sufficient
for
effectively
rolling
obsess
itself,
but
the
acceptable
limitations
of
sas
are
that
it's
a
single
package.
It
doesn't
have
any
compartment
edges
that
exit
a
single
package,
which
is
to
say,
no
depend
no
no
dependencies
from
sas
to
anything
else
and
it
also
doesn't
have
live
binding
support
and
it
also
does
not
have
support
for
common
js
or
any
of
the
other
things.
B
Right,
I
also
had
another
interesting
question
is
since
we
need
to
create
static
module
records
and
we
don't
really
count
well,
we
can't
trust
snaps
right,
so
we
can't
do
it
during
compile
time.
I
was
thinking
the
snap
itself
could
provide
a
list
of
experts,
but
it
could
provide
false
exports.
So
from
what
I
understand
at
the
current
state,
we
need
to
have
the
whole
parts
are
included
in
the
in
the
bundle
pretty
much
right
to
parse.
This.
A
A
That's
that's
a
format
that
uses
a
base64
encoded,
zip
file
that
contains
all
of
the
pre-compiled
static
module
records
for
all
of
the
modules
in
a
compartment
map
that
describes
how
to
link
them
again
using
the
compartment
at
runtime,
but
use
it,
but
only
using
the
static
module
record
constructor
at
that
bundle.
Time
whenever
you
do
that
there,
which
is
to
say
yes
to
create
a
bundle,
requires
a
full
javascript
parser.
A
B
B
Of
well
from
what
I
understand,
the
flow
would
be
that
we
we
bundle
the
snap
on
the
client's
computer.
They
use
a
developer's
computer,
which
includes
pre-compiled,
static
module
records,
and
then
we
we
run
that
on
the
extension
side,
and
we
run
that
in
a
compartment
and
then
what?
If
the
developer,
is
malicious
and
modifies
the
precompiled
static
module
records
to
provide
to
have
data
that
is
not
actually
inside
the
source.
A
A
That
would
induce
the
compartment
to
give
them
an
incorrect
bag
of
updaters,
which
they
could
do
anything
they
want
with
that
they
could
that
they
could
contrive
a
a
functor
that
can
that
receives
those
updaters,
which
is
to
say
that
they
can
claim
to
import
and
export
different
names
than
they
actually
imported
exported.
It
turn
and
then
update
those
values.
A
A
So
basically
they
could
claim
to
import
some.
Basically,
they
can
do
what
you
can
do,
what
what
they
could
induce
through
manipulation
of
their
static
module
record.
They
could
also
there's
nothing
that
they
can
do
by
manipulating
their
static
module
record
that
they
couldn't
already
do
by
writing
a
different
program
in
javascript,
good.
C
That's
that's.
That's
the
essential
invariant
is
that
the
the
the
the
male
corrupted
I'm
sorry,
the
male
compiled
module
is
just
in
terms
of
its
potential
for
damage
to
the
integrity
of
other
modules
is
equivalent
to
simply
a
malicious
program
in
that
position.
Constrained
by
all
the
same
constraints.
C
A
Wonderful
yeah
and,
of
course,
feel
free
to
reach
out
to
us.
I'm
sure
that
aaron
or
whomever
you
are
most
in
contact
with
can
hook
you
up
with
all
of
our
communication
channels.
We
have
one
on
matrix
and
we
also
and
agorik
and
metamask,
have
a
communication
channel
as
well.
That
we'd
be
happy
to
have
you
in.
A
A
Does
everybody
see
pull
request,
narrow
focus
of
proposal
to
module
loading
hi
okay?
So
this
is
a
rewrite
essentially
of
the
readme
for
the
compartment
proposal,
and
the
focus
of
this
is
based
off
of
this
hasn't
been
updated
in
a
year.
So
a
great
deal
has
changed
about
how
we
intend
to
present
the
compartments
proposal
to
tc39
what
our
aims
are
for
this
initial
version
of
compartment
and
how
it
relates
to
the
broader
cess
proposals,
specifically
lockdown,
the
original.
A
Those
are
that
most
of
the
virtualization
hooks
well
pardon
that
the
only
virtualization
hooks
we
need
in
order
for
the
compartment
to
be
useful
in
conjunction
with
lockdown,
are
the
module
loader
api
and
also,
coincidentally,
and
and
also
having
creating
narrowing
the
focus
of
the
compartments
in
the
api.
Initially
to
just
the
host
virtualization
hooks
for
module.
A
Loading
gives
us
an
opportunity
to
recruit
more
allies
for
its
advancement,
so
so
so
one
of
the
a
large
part
of
what
I've
done
with
this
is
in
the
section
on
motivation
calling
out
specifically
who
we
wish
to
be
our
allies
in
advancing
this
proposal,
which
is
to
say,
people
who
are
building
bundlers.
People
are
building
tooling
around
testing
and
things
like
that.
That
need
a
module,
loader
api
and
I've
dropped
from
the
proposal
host
virtualization
hooks.
A
I
I
do
not
even
mention
post
virtualization
hooks
for
things
like
time
zone
and
stuff
like
that.
That
we
know
would
meet
resistance
from
potential
allies,
with
the
hope
that
that
we
would
have
a
follow-up
proposal
for
specific
ones
on
an
as
on
a
case-by-case
basis,
so
that
we
can
meet
those
conversations
head
on.
A
A
C
So,
with
regard
to
putting
postponing
the
fights
rather
than
painting
ourselves
into
a
corner,
because
the
host
hooks
would
be
new
options
with
new
names
in
an
options
bag
a
later
proposal,
adding
a
host
hook
would
be
compatible.
You
know
compatible
as
a
follow-on
proposal.
It
wouldn't
break
anything
built
to
the
earlier
proposal.
Is
that
correct?
That
is
correct,
yeah,
okay,
the
other.
The
other
question
I
have
is
so
you
say
this
is
sort
of
specialized
for
module
loading
and
you're
omitting
virtualization.
C
A
A
C
A
C
So
my
concern
with
we
so
in
general,
we've
been
very
careful
to
design
the
the
non-locked
down
language
and
the
lockdown
language
so
that
most
code,
the
vast
majority
of
code
written
to
the
non-lockdown
language
that
stay
within
best
practices,
happens
to
be
runnable
compatibly
in
the
locked
down
language.
So
we've
tried
to
keep
and
if
the
semantics
of
compartment
is
changed
too
much
by
lockdown,
then
compartment
itself
becomes
an
abstraction
that
violates
that
rule
such
that
code.
A
C
Okay,
so
you've
met
some
of
them,
okay,
so
select.
So
let
me
ask
a
question
and
so
that
people
people
who
know
about
dino
like
bradley,
can
answer
as
best
as
they
can.
Are
they
looking
for
compartments
with
separate
globals
with
in
the
absence
of
lockdown?
So
are
they
not
interested
in
freezing
the
primordials.
E
C
C
The
primordials,
if
they're,
not
sharing,
if
they're
not
I
mean,
if
they're
sure,
if
they're
sharing
the
primordials
and
the
primordials
are
not
locked
down,
then
obviously
they're
not
protected
from
each
other's
misbehavior
and
if
they're
not
sharing
primordials.
If
they
have
their
own
separate
primordials,
then
it's
not
a
compartment
api.
It's
a
realms
api.
A
Yeah,
I
don't
disagree
on
any
of
these
points.
I
I
also
very
much
feel
but
pardon
to
clarify
bradley.
My
intention
is
for
the
compartment
api
to
provide
global
virtualization
after
lockdown
they
and
I
think
that
the
dino
folks
need
a
post-lockdown
compartment,
not
a
pre-lockdown
compartment.
I'm
suggesting
that
there
are
other
potential
allies,
for
example,
people
writing
things
like
browserify
or
webpack,
or
parcel
that
those
kinds
of
programs
that
will
that
will
will
want
the
ability
to
at
least
pass
the
global.
This
from
the
surrounding
compartment
in.
D
A
D
A
A
C
A
C
So
the
one
qualifier
there
that
we've
gotten
we've
gotten
feedback
from
engine
manufacturers
in
the
past
that
they
don't
want
you
to
be
able
to
specify
an
arbitrary
object
to
serve
as
the
global
this
for
a
new
compartment.
Okay,
that
it
has
to
be
a
object
that
was
created
to
serve
as
a
global.
This.
E
Ahead
so
there's
a
few
things
commenting
on
about
the
most
recent
thing:
where
it's
a
specialized
object.
All
engines
do
support
essentially
proxy
traps,
I
think,
accept
excess,
so
you
can
provide
proxy
traps
to
the
globals,
which
might
be
sufficient
that
you
don't
actually
need
to
provide
an
actual
value.
E
So
I
wouldn't
worry
too
much
about
that.
The
other
thing
is
one
use
case
that
node
was
looking
at.
It's
somewhat
been
abandoned.
Now
is
censorship
of
two
historic
unfortunate
globals
that
are
on
globalness,
which
are
process
and
buffer,
and
we
have
tried
various
ways,
including
nasty
call
site
checks,
and
nothing
is
sufficient
to
really
mock
them
out
and
really
lock
you
away
from
them
besides,
creating
a
new
global
okay.
This
gets
more
complicated,
though,
because
people
sometimes
declare
global
variables
and
so
the
global
contour,
whatever
you
want
to
call
it.
C
E
E
C
A
Yeah
yeah,
when,
when
this
compartment
proposal
starts
getting
written
as
speckeys
we're
definitely
going
to,
if
it
includes
evaluate,
we
will
probably
be
compelled
to
do
interesting
things
to
specify
interesting
things.
We
can't
shim
with
regard
to
the
global
contour
for
cases
like
this
and
rebels,
and
such
I
should
add
that
to
the
list
of
motivations,
because
creating
a
rebel
is
one
of
the
things
that
this
would
help
with.
C
A
D
A
Yeah
yeah,
which
is
to
say
yeah,
so
we
need.
We
need
to
invent
a
way
to
specify
this.
That
satisfies
the
constraint
that
mark
mentioned
earlier.
That
I
did
not
know
about
which
was,
which
is,
I
believe,
the
motivation
for
the
endowments
argument
for
compartment,
and
that
is
that,
if
a
compartment
has
a
unique
global,
this
and
consequently
unique
evaluators.
A
So
I
propose
a
straw
man
that
you
pass
in
a
global
this
that
doesn't
work
because
of
the
the
browser,
the
browser
limitation
on
globals,
so
alternately.
The
mode
would
be
just
share
the
globalness
of
the
parent
compartment
and
consequently,
it's
evaluators,
in
which
case
the
endowments
trick
doesn't
work.
Because
if
you
were
to
pass
global
this
your
own
global
this.
In
as
the
endowments
object
for
a
compartment
as
as
currently
implemented,
you
would
get
all
of
the
properties
of
the
globals
from
the
outer
compartment,
including
its
evaluators.
D
D
A
Right,
but
if
you,
but
if
you,
if
the
api,
supports
an
endowments
argument,
that
is
to
say
properties
that
should
be
copied
to
the
compartment's
own
global,
this
one
of
the
valid
ways
to
use
that
for
part,
maybe
not
valid.
One
of
the
ways
that
it
will
inevitably
be
used
is
passing
the
global
this,
your
own
global.
This
in
as
the
endowments
object
for
a
compartment,
but.
C
A
I
agree:
okay,
absolutely
agree.
Is
it
so
provided
so
assuming
based
off
of
our
agreement
that
the
behavior
is
that
the
properties
of
the
parent
global
this
are
copied
to
the
child
global?
This?
You
would
be
in
a
strange,
hybrid
situation,
where
eval
would
be
implicitly
indirect
in
that
compartment.
C
Oh,
that's
interesting,
yeah,
the
the
evaluators
would
be
would
come.
You
know
if
you
provide
evaluators
in
an
endowment
which
in
this
case
you
would
be
effectively
doing
then
those
evaluators
would
replace
the
the
new
global's
own
evaluators.
So
you'd
be
in
a
situation
where
you
have
the
new
global.
This
with
copied
properties,
but
among
those
properties,
are
the
evaluators
which
evaluate
in
the
context
of
the
old
globalness.
A
C
C
A
C
A
D
A
C
A
C
C
C
C
D
C
A
D
C
D
C
You
know
you
know
the
the
the
analog
of
what
we
do
with
lockdown
compartments.
It's
just
that
each
global.
Every
time
you
create
a
new
global
under
normal
conditions,
you
give
it
its
own
global,
evaluators
and,
and
the
language
right
now
has
exactly
well.
Language
with
compartments
proposal
would
have
exactly
oh
four
global
evaluators.
I
suppose
eval
function,
compartment
and
realm.
I'm
confused
about
realm.
A
E
C
Lock
down
not
by
changing
the
definition
of
compartments,
but
just
by
doing
the
repair
of
by
doing
the
repair
of
the
intrinsics
that
we're
already
specifying
that
it
does
replaces
the
shared
functions,
prototype
dot,
com,
dot,
constructor
to
point
at
an
inert
function
constructor.
So
I
think
this
is
all
a
consistent
story.