►
From YouTube: EcmaScript TC39 Compartments Update July 2022 Reprise
Description
This is a recorded reprise of the presentation Kris Kowal gave at ECMA TC39 on July 19, 2022, revealing a new layering of the Compartments proposal (stage 1) that aligns each of those layers with different motivating cases and provides a coherent framework for module proposals going forward.
A
A
I
had
an
opportunity
to
speak
again
about
what
can
we
do
about
this
new
common
js
menace
that
we've
created
and
and
since
then
a
long
time
has
elapsed,
and
this
is
an
update
on
the
compartments
proposed?
Oh
pardon
what
I
learned
from
that
experience
was
two
things.
First,
under
no
circumstances
should
you
ever
attempt
to
tell
a
joke
at
plenary,
and
the
other
thing
I
learned
was
to
never
under
any
circumstances,
present
a
proposal
for
a
module,
constructor
and
we'll
just
see
how
that
goes.
Shall
we.
A
A
A
The
we
found
that
it
was
possible
to
reconstruct
the
compartment
in
terms
of
these
finer
of
these
smaller,
smaller
layers
and
you'll
notice,
as
we
go
through
those
layers
that
each
of
these
layers
has
different
motivating,
use
cases
and
unlocks
different
different
usage
of
the
module
system,
each
of
which
might
have
different
proponents
and-
and
it
allows
us
to
build
different
coalitions
around
developing
each
of
the
layers
of
this
proposal
with
different
interested
parties.
So
not
everybody
is
interested
in
all
of
these
layers.
Some
people
are
only
interested
in
any
of
these
layers.
A
If
we
get
all
of
them,
and
some
people
are
more
are
interested
in
different
subsets.
So
there
are
some
dependencies
along
these
layers.
It
isn't
it
isn't
strictly
layered.
We
don't
have
to
get
every
single
one
of
these
into
the
language
in
order
to
make
progress.
They
unlock
different
things
at
different
points,
but
the
first
layer
is
is
foundational
not
just
to
the
compartment
proposal,
but
to
other
proposals
that
are
in
flight
as
well
at
layer
0
we
and
we
would
introduce
a
first
module,
constructor
and
module
source
constructor.
A
This
would
unlock
the
ability
to
do
multiple
instantiation
of
modules
and
also
unlocks
deferred
execution
in
in
relation
to
other
proposals
and
serves
as
a
foundation
for
these
other
proposals,
so
that
they
share
some
common
ground
on
which
we
can
reason
about
how
coherent
all
of
these
module
proposals
are.
Then
a
layer
down.
A
We
would
introduce
module
reflection,
that
is
to
say,
to
to
make
it
possible
to
see
that
to
statically
analyze,
a
module
without
executing
it,
and
that's
useful
for
creating
bundlers
for
building
import
map
tooling
and
other
use
cases,
and
then
a
layer
underneath
that
or
above
which
way
is
up.
First,
we
would
introduce
first
class
module
sources,
and
what
this
would
allow
us
to
do
is
to
virtualize
the
notion
of
a
module
that
participates
in
the
javascript
module
graph,
such
that
other
languages
can
participate
as
well
in
with
definitions
in
user
code.
A
the
layer
underneath
that
is
evaluators.
Now
we
need
evaluators
to
make
compartments,
they
would
say
evaluators
are
a
mechanism
for
isolating
the
global
scope
for
for
any
of
the
three
ways
that
the
language
would
allow
us
to
evaluate
text
and
allow
us
to
evaluate
a
module
or
a
program
or
a
script
in
the
context
of
a
different
global
object.
But
it
happens
to
be
that
this
is
also
useful
for
for
creating
composable
dsls,
that
is
to
say,
we
currently
have
jasmine,
jest
and
grunt
and
other
kinds
of
dsls.
A
Cooperate
when
you
have
multiple
modules
and
different
dsls
in
the
same
program,
evaluators
would
allow
us
to
make
that
more
composable
and
then,
on
top
of
that,
with
lockdown
and
compartments,
we
would
be
able
to
do
the
full
agenda
4
compartments,
which
is
both
lockdown
and
isolation
of
an
ecosystem,
so
that
we
can
defend
a
program
against
supply
chain
attacks
by
minimizing
the
authority.
That's
given
to
third-party
dependencies.
A
So
let's
go
in
and
take
a
look
at
each
of
the
layers
in
phase
0,
I
propose
first
class
modules
and
a
module
source
constructor
that
what
this
would
look
like
is
a
module
source
constructor,
which
returns
an
object
that
represents
the
compiled
artifact
of
of
a
module
source.
This
is
this:
does
not
initialize
or
execute
any
code.
A
A
A
Then,
supposing
that,
if
but
suppose,
instead,
you
created
two
module
instances
from
the
same
source,
you
would
amortize
the
cost
of
compiling
the
source,
but
be
able
to
get
separate
instances.
This
becomes
significant
later
on
when
it's
possible
to
create
multiple
instances
in
different
evaluator
scopes,
but
but
in
general
this
means.
The
idea
is
that
we
memoize
we
do
not.
We
don't
have
we
don't
so
much
as
memoize
module
instances.
We
just
ensure
that
we
only
get
one
namespace
object
for
every
module
instance.
A
We
get
one
one
to
one
to
one
relationship
of
all
the
things
corresponding
to
a
module
instance
per
construction
of
a
module,
and
this
is
what
it
looks
like
to
virtualize
the
import
graph.
You
would
provide
an
import
hook
which
receives
an
import
specifier
and
tentatively.
An
import
meta
object
and
the
responsibility
of
the
import
hook
is
to
take
these
two
pieces
of
information
and
provide
another
module
instance,
and
it
does
not
again
matter
whether
the
module
instance
is
initialized
or
not.
It
can
be
in
a
non-initialized
state
or
a
later
state.
A
The
point
of
this
is
that
you
can
create
a
bank
of
uninitialized
modules
or
a
combination
of
uninitialized
initialized
modules
and
then
build
a
module
graph
by
driving
the
import
hook
and
the
host
apart.
The
engine
javascript
would
drive
the
import
hook
when
you
called
dynamic
import
on
a
module,
and
then
it
would
advance
all
of
the
transitive
dependencies
to
their
final
state.
A
And
so
the
responsibilities
of
an
import
hook
are
to
resolve,
locate
and
fetch
and
then
compile
and
return
a
module
instance
for
a
particular
specifier
in
a
particular
module,
as
identified
by
the
import
meta.
So
import
hooks
are
reusable
across
multiple
module
instances,
which
is
an
important
factor
for
memory
and
and,
and
importantly,
this
means
that
an
import
book
can
take
over
the
all
of
these
individual
concerns
and
provide
separate
solutions
for
them.
A
For
example,
resolution
is
dependent
on
the
host
environment
and
done
in
different
ways,
depending
on
what
host
you're,
emulating,
locating
can
be
based
off
of
locating
and
fetching
can
be
based
off
of
any
storage
mechanism
and
address
space
that
you
receive
the
module
texts
from
so
that
is
to
say
it
could
be
a
database.
It
could
be
a
zip
file,
it
could
be
the
web,
it
could
be
your
file
system
and
this
this
mechanism
allows
any
host
to
emulate
any
other
host.
With
this
hook.
A
A
In
order
to
unlock
more
benefits
from
having
this
foundation,
the
first
layer
would
be
module
reflection,
and
this
would
allow
us
to
write
tools
that
are
able
to
analyze
an
import
graph
and
construct
and
by
by
constructing
module
sources
that
can
in
which
we
can
analyze
their
their
shallow
imports.
And
then,
from
this
we
can
build
tools
that
build
out
entire
dependency
graphs.
That
means
we
could
build
something
that
generates
an
import
map.
We
can
write
a
bundler.
A
So
for
if
you
wanted
to
go
beyond
ecmascript
modules
and
allow
modules
from
other
languages
to
participate,
we
need
a
way
to
create
different
kinds
of
module
sources
that
can
participate
in
the
graph.
And
so
we
come
up
with
a
protocol
where
a
source
can
declare
what
its
bindings
are,
such
that
the
machinery
behind
the
module
loader
can
go
off
and
do
fetching
of
transit
dependencies
and
provide
an
initialize
or
execute
or
a
function.
Similarly
named
that
that
serves
the
purpose
of
when
it's
the
time
in
the
execution
of
all
of
the
modules.
A
This
is
the
behavior
that
corresponds
to
this
particular
thing,
and
with
this
we
can
build
common
js
support
very
high
fidelity,
common
gs,
support
for
the
subset
of
common
js.
That
is
already
bundleable,
which
is
to
say
that
the
ecosystem
has
already
herded
a
large
portion
of
the
common
js
dependency
tran
libraries
into
an
ecosystem
where
largely
they
are
bundleable
if
they
need
to
be
bundleable
and
if
they
fit
that
subset.
That
is
heuristically
analyzable,
where
you
can
say
hey
if
there's
a
require
function,
followed
by
a
string.
A
A
A
With
this
global
object,
import
hook
and
import
meta
and
the
import
hook
and
import
meta
are
not
necessarily,
they
are
not
useful
for
the
module
constructor
right
because
it
has
its
own,
though
it
could
default
to
these
from
the
evaluator,
but
but
but
the
use
for
them
is
actually
because
dynamic.
Import
is
also
supported
in
script
context.
A
So
if
you
were
to
eval
within
a
module
or
eval
with
a
within
a
function
or
use
dynamic,
import
directly
within
a
function
body,
the
import
hook
and
import
meta
provided
here
to
the
evaluators
constructor
would
be
used,
and
this
gives
us
the
ability
to
fully
isolate
isolate
code.
That's
running
so
that
it
only
sees
the
the
the
the
the
global
object.
A
It
is
also
happens
to
be
useful
for
other
things
like
creating
these
composable
dsls.
Currently
dsls
like
jasmine
or
jest,
have
to
punch
the
shared
global
object
with
functions
like
describe
or
whatnot
or
before
or
after,
and
in
order
for
these
to
work,
they
either
have
to
be
in
separate
realms,
which
has
its
own
caveats
and
and
hazards
like
identity.
Continuity
by
identity,
discontinuities
become
possible
in
those
environments,
or
they
choose
a
more
lightweight
solution
where
they
just
say.
A
We
are
going
to
only
allow
one
dsl
evaluation
to
occur
concurrently
and
we'll
just
keep
a
a
name
and
dynamic
scope
that
associates
those
function,
calls
with
the
files
that
they
originated
from
and
alternately.
You
can
do
dsls
using
with
blocks
for
much
the
same
purpose
as
they
evaluate
some
code
in
the
context
of
a
width
block,
and
then
you
can
decide
and
provide
closures,
but
well
with
this,
we
can
do
something
much
more
graceful
we
can
allow.
A
We
can
allow
somebody
to,
for
example,
let
me
pull
up
the
dsl
with
this.
We
would
be
able
to
say
I
want
to
construct
a
new
set
of
evaluators,
I'm
going
to
provide
a
global
this
which
inherits
from
the
existing
global,
but
I'm
going
to
give
it
specific
described
before
and
after
functions
and
in
this
case,
you're
running
their
code
in
an
environment.
A
That
you've
been
lined
into
your
initial
html
and
if
that's
the
case,
you
might
still
want
a
natively
implemented
compartment,
because
then,
in
that
case,
you
would
not
have
to
write
this
you'd
not
have
to
inline
this
code.
Similarly,
for
for
the
embedded
systems
use
case
there.
Similarly,
you
might
your
code
segment.
A
But
that
is
speculative
and
that's
that's
the
presentation
as
a
whole
and
I
at
plenary.
I
I
provided
this
very
brief,
actually
represent
a
presentation
for
a
90-minute
speaking
slot,
knowing
that
modules
are
kind
of
the
third
rail
when
it
comes
to
inviting
people
to
talk
about
them
in
a
standards
body
and
there's
plenty
to
talk
about.
A
A
I'm
being
so
very
careful
of
representing
you's
point
of
view,
it
is
in
the
notes,
please
feel
free
to
check
the
minutes
from
from
plenary,
but
we
were
surprised.
We
were
surprised
by
his
reception
and
and
and
though
he
did
what
was
hesitant
about
evaluators
and-
and
we
also
received
some
surprising
support
from
a
delegate
from
bloomberg,
who
was
actually
really
excited
about
evaluators
for
cases
beyond
the
the
compartment
use
case
and
rob
palmer.
C
A
Indeed,
this
is
not
actually
any
commentary
about
unicode,
though
I
thank
you
for
reminding
me.
I
I
I
think
that
at
plenary
I
failed
to
give
chip
credit
for
a
horrible
idea
on
plenary
bingo,
where
I
suggested
that
that
I
think
that
there
should
be
a
metagame
or
plenary
bingo
where
delegates
are
challenged
to
construct
the
proposal
that
fills
the
largest
contiguous
section
of
their
bingo
card
of
someone's
bingo
card,
for
example,
wow.
A
B
B
I
noticed
that
this
time
that
I
didn't
notice
originally
that
on
chris's
layers
slide
layer,
five,
it
does
say
lockdown
and
compartments,
not
that
slide
the
that
one
does
say
lockdown
and
compartments,
but
then
the
the
talk
itself
only
explain
compartments,
shu
hearing.
Only
the
explanation
of
evaluators
and
compartments
without
an
explanation
of
lockdown
correctly
objected
that
there
there's
not
enough
mechanism
here
to
actually
provide
the
isolation,
and
that-
and
it's
only
once,
you
also
explain
lockdown-
that
we
can
understand
how
these
mechanisms
together
provide
the
isolation
benefits.
A
Yeah
the
idea,
so
I
proposed
to
shoot
the
delegate
from
google
that
an
alternative
alternative
way
to
get
compartments
that
is
coherent
would
be
not
to
provide
a
compartment
primitive,
but
to
provide
a
lockdown
primitive.
That
reveals
a
compartment
and
harden,
but
it
in
their
whole.
This
so
shu
made
the
the
the
comment
that
it's
hard
to
get
that
right
and
he's
true
and
it's
true.
A
So
the
idea
is
what
if,
instead
we
we
came
back
to
tc39
with
a
proposal
for
for
lockdown
and
it's
full,
but
like
currently
the
the
premise
is
that
if
we
had
all
of
these
primitives,
we
could
implement
lockdown
entirely
in
user
space
and
not
trouble
the
user
with
it,
and-
and
I
think-
and
I
do
still
feel
that
that
is
the
right
way
to
go
forward,
because
enshrining
too
much
in
the
specification
has
its
own
set
of
risks.
But
let
me
talk
a
bit
about
what
lockdown
does.
A
There
are
a
number
of
other
constructors
like
the
date
constructor
and
the
math
namespace,
which
are
also
per
compartment
and
they're
per
oh
wait.
No,
that's
not
true!
Now
those
are
also
shared,
but
they're
not
the
same
as
the
ones
in
the
original
they're,
not
in
the
same
as
in
in
the
original
realm,
because
they
need
to
have
certain
behaviors
removed.
So
like
the
date
constructor
is
denied
by
default,
the
ability
to
tell
time
it's
only
allowed
to
compute
about
times
relative
to
each
other
and
math.
A
Intel
is
simply
omitted
from
the
shared
intrinsics
because
it
with
there's
no
easy
way
to
make
it
possible
to
share
intel
across
compartments,
which
is
to
say
that
that
the
nature
of
lockdown
is
that
it
provides
a
view
into
a
subset
of
the
intrinsics.
The
frozen
shared
subset
of
the
intrinsics
that
I
think
is
likely
to
evolve
and
grow
over
time
carefully
and
it
may
and
whether
the
right
venue
to
evolve
and
grow
that
the
right
venue
for
the
evolution
of
lockdown
is
262
or
user.
B
But
in
any
case,
the
the
lock
down
the
compartment
layer,
I
can
certainly
see
breaking
it
off
into
a
separate
proposal
that
that
makes
its
way
through
committee
following
the
the
first
four,
but
I
do
think
it
neat.
It
does
need
to
go
into
the
standard
for
several
reasons.
One
is
that
xs
builds
it
into
the
platform
and
53
will
be
standardizing
on
it,
because
there
is
no
free
lockdown
situation
in
the
embedded
context.
The
the
the
result
of
lockdown
is
all
that
embedded
code
sees.
B
B
That
would
freeze
those
primordials
if
it,
if
they're
not
frozen.
You
know
it's
impossible
to
write
shim
code
that
would
that
written
in
ignorance
of
of
the
the
new
proposal
that
would
succeed
at
freezing
those
primordials
and
if
they're
not
frozen,
then
you've
created
a
security
hole
once
lockdown
becomes
part
of
the
spec,
then
the
invariant
can
be
maintained
by
making
coordinated
changes
in
the
spec
to
to
include
in
the
frozen
primordial
set
all
primordials
that
are
introduced.
C
I
think
that's
a
really
important
point
and
something
that
I
hadn't
twigged
to
until
you
said
it
just
now
with
respect
to
what
the
tc53
thing
points
out
is
that
lockdown
is
actually
has
sort
of
two
aspects.
One
is
the
semantics
of
lockdown
meaning.
What
does
it
mean
to
be
in
a
lockdown
state
in
terms
of
what
you
can
and
cannot
do,
and
the
other
is
the
api
for
lockdown,
which
is
what
is
the?
B
Yeah
some
other
important
changes
that
lockdown
does
is
evaluation
within
the
locked
down
system
is
only
strict
mode.
Javascript
sloppy
mode
has
been
removed
from
existence
in
the
lockdown
system,
and
indeed
the
shipping
tc53
and
and
moddable
in
that
configuration
just,
doesn't
need
any
mechanism
in
the
shipping
virtual
machine
in
the
rom
for
supporting
javascript
sloppy
mode.
B
Another
one
is
that,
in
order
to
have
the
evaluation
evaluation
only
per
compartment,
we
have
to
lock
down
rewires
the
the
evaluator
prototype,
specifically
function.prototype
its.constructor
points
at
an
inert
function.
Constructor
one
that
only
throws
that
would
also
happen
with
a
module.prototype
would
be
an
inert
module
constructor.
A
I
wonder
where
my
head
was
so
so
in
terms
of
ways
forward
for
hardened
javascript
at
tc39.
There
are
essentially
two
one
way
forward
is
that
we
get
layers
zero,
one
and
three,
which
are
sufficient
to
have
an
ecmascript
module
system
that
that
under
lockdown
implemented
in
user
code
there's
an
and
the
objection
that
shu
from
google
has
to.
That
is
that
waiters
and
evaluators
are
certainly
the
most
risky
the
most
risky
of
these.
These
primitives
and
I
believe
the
position
is
that
they
would
be
difficult
to
use
correctly.
A
A
B
A
A
Have
this
thing
called
a
global
contour
which
is
not
currently
specified
in
262,
but
it
essentially
allows
evaluating
the
evaluation
of
multiple
programs
in,
in
the
context
of
a
particular
to
grow
the
global
controller,
which
is
to
say
that
anything
defined
by
the
let
or
const
from
a
previous
evaluation
would
can
would
persist
between
calls
to
eval
and
not
eval
necessary
but
like
if
there
were
an
eval
script
method
added
to
the
evaluator
bag.
For
example,.
B
C
B
A
There's
also,
it's
also
the
the
case
that
what
the
invariant
we
actually
need
in
order
to
get
in
order
to
preserve
the
integrity
of
lockdown
shims
in
the
wild
over
time
is
that
it
isn't
that
we,
it
isn't
as
strong
as
it
is
like.
The
easiest
way
to
say
is
that
to
express
our
desire
is
hey.
No
new
intrinsics
should
be
added
to
the
language
that
that
are
that
can't
be
discovered
by
a
property
walk
from
the
global.
A
This
of
the
of
the
base
realm
that
is
stronger
than
we
actually
need
a
more
relaxed
way
of
putting
that
would
be
to
say
that
we
we
need
there
to
be.
No,
we
need
need
to
be
impossible
for
an
intrinsic
to
be
revealed
by
any
mechanism
if
it
is
not
if
it
is
not
also
by
any
mechanism
from
the
position
of
a
shared,
an
existing
shared
intrinsic
of
a
compartment
right.
A
So
if
intel,
for
example,
which
doesn't
participate
in
this
adds
a
method
that
returns
an
object
with
a
prototype
that
isn't
that
isn't
discoverable
by
a
property
walk
from
global
this
in
the
incubator
realm,
that's
not
actually
a
problem
for
us.
Iterator
help
helpers
are
but,
but
our
position
is
even
more
relaxed
than
that
is
that
if
any
of
those
objects
are
added
to
the
language
as
long
as
they're
also
exposed
by
some
well-known
mechanism
for
enumerating
the
in
the
enumerating,
the
discoverable
shared
intrinsics
of
of
a
compartment.
A
Specifically,
that
would
be
sufficient
for
our
purposes
right.
The
so
like
an
alternate
view
of
this
would
be
that
there's
another
proposal
called
get
intrinsics
that
jordan
harbin
is,
is
pushing
that
would
allow
him
to
have
a
function
in
global
scope
that
could
be
used
to
find
the
original
intrinsic
for
any
name
in
the
language.
A
B
Yeah
I
mean
every
time
we
say
to
the
authors
of
some
proposal
of
the
proponents
of
some
proposal.
No,
you
can't
do
that
because
it
would
break
our
ability
to
write
a
secure
shim.
It's
always
a
fight
because
they're
not
using
our
secure
sham,
whereas
once
it's
in
once
it's
in
the
language
and
it's
the
responsibility
of
tc39,
to
maintain
the
security
of
the
item
that
is
now
in
the
language
for
providing
the
safety
exactly
yeah.
It.
A
A
B
Yeah
but
but
the
the
even
with
even
prior
to
adoption,
I
think
we're
underestimating
the
effect
on
the
committee
process.
So
let
me
use
an
example.
We
now
have
accepted
in
stage
three,
which
means
it's
effect.
You
know
effectively
understood
to
be
part
of
the
language,
the
realms
proposal
with
the
callable
boundary
that
prevents
any
entangling
of
the
object
graph
nobody's
using
it.
Yet
it
has
zero
adoption
in
the
wild,
or
rather
you
know
outside
of
salesforce.
B
But
if
anybody
were
to
think
of
a
proposal
where
a
consequence
of
the
proposal
would
be
to
breach
the
object
graph
isolation,
it
would
be
immediately
a
dead
letter
without
a
fight
in
the
committee,
because
everybody
understands
that
the
isolation
of
the
object
graph
is
now
an
invariant.
We
need
to
defend
because
we
have
accepted
realms
with
that
security
property
into
the
language.
C
Well,
there's
also
there's
also
a
yeah
it
it.
It
alters
the
default
in
the
in
the
argument
which
is
instead
of
justifying
you
know,
I
mean
there's
a
lot
of
stuff
where
we're
trying
to
argue,
for
you
know
for
something
like
a
lockdown
or
or
isolation
mechanisms,
and
we
get
pushback.
That's
it's
in
the
form
of
sort
of
vague
well.
Maybe
that
might
get
in
the
way
of
some
hypothetical
future
use
case.
C
Mumble
mumble
that
somebody
might
want
to
do
something
that
would
be
blocked
by
that
mumble
mumble,
as
opposed
to
the
scenario
that
you
just
outlined
mark,
which
is
somebody
proposing
a
very
specific
thing,
which
is
not
some
mumble
mumble
hypothetical
future
use
case.
It's
a
concrete
proposal,
at
which
point
you
can
ask.
So
why
do
you
want
to
do
that
and
you
can?
You
can
push
back
on
it
with
with
pointed
reasoned
argument,
because
you're
not
arguing
against
some
vague
thing,
you're
arguing
against
something
specific.