►
From YouTube: SES-mtg: sep30 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
All
right
for
the
record
mark,
you
had
words
about
the
status
of
the
built-in
module
proposal,
as
of
our
last
tc
39
and
yeah,
and
a
good
opportunity
to
get
michael's
reflections
on
that
as
well.
B
Okay,
so
so
at
the
last
tc-39
meeting,
built-in
modules
in
the
in
the
form
of
that
proposal
got
blocked
by
google
and
mozilla
specifically,
so
in
that
sense,
that
form
of
the
proposal
is
no
longer
a
live
proposal.
B
What
several
of
us
have
discussed
offline
is
that
the
right
way
to
proceed
with
the
concerns
addressed
by
that
proposal
is
to
proceed
with
compartments
first,
since
compartments
allow
javascript
code
to
create
a
module
and
import
environment
for
other
for
other
javascript
code
and
then,
as
once,
that's
worked
out
and
solid,
then
revisit
the
concerns
behind
built-in
modules.
A
Yeah,
and
with
that
as
context,
we've
invited
michael
to
join
us
michael,
was
the
champion
for
4,
is
the
champion
for
built-in
modules
and
expressed
an
interest
in
in
what
we're
doing
for
compartments
and
welcome.
Michael.
D
Can
someone's,
maybe
michael,
can
summarize
the
concerns
I
was.
I
wasn't
able
to
join
the
last
week
meeting.
Can
you
summarize
the
the
concerns
that
they
raised?
The
mozilla
and
and
google
raised
on
built-in
modules
that
could
be
addressed
by
the
compartments.
C
So
I'm
not
sure
that
the
concerns
that
they
raise
can
be
addressed
by
compartments,
but
I
will
share
the
concerns
that
they
were
raised
and
there
have
been
prior
concerns
that
I
believe
that
we
had
worked
through
and-
and
these
concerns
were
actually
somewhat
somewhat
new
to
to
us-
and
the
concerns
were
they're
the
same
for
both
google
and
for
mozilla,
and
the
concerns
are
that
web
developers
will
have
no
inclination
whatsoever
to
use
a
module-based
approach
to
access
functionality
and
would
continue
to
use
the
global
object
and
and
the
web
standards
organizations
would
not
put
any
new
functionality
in
into
a
module.
C
Google
said
that
that
was
a
hard.
No.
They
also
said
that
that
they
were
very
unlikely
to
support
any
new
functionality
in
in
tc39
being
placed
in
the
module.
C
But
what
I
thought
was
curious
is
they
were
in
support
of
the
built-in
module
technology
itself.
The
feature
itself
and-
and
I
was
left
kind
of
scratching
my
head-
so
you're-
willing
to
support
a
feature
that
you
don't
want
to
use,
and
I
think
that
part
of
it
is
that
they
were
willing
that
other
host
environments,
non-browser
host
environments,
could
use
it.
But
but
then
there
started
being
some
philosophical
discussion
that
I
thought
was
important
that
we
don't
want
to
have.
We
don't
want
to
add
new
features
that
kind
of
split.
C
C
I
I
think
in
the
end
google
saw
and
mosul
saw
that
it
didn't
make
sense
to
add
a
feature
that
they
weren't
going
to
use
and-
and
we
didn't
want
to
split
split
javascript,
so
they
they
objected
on
the
grounds
that
they
would
not
use.
They
would
not
support
the
use
of
the
feature.
So
that's
that's.
You
know
in
a
nutshell,
I
think,
what's
going
on,
I
think
underlying
this.
C
A
little
bit
is
that
the
proposal
advocated
and-
and
I
think,
there's
fairly
strong
support
on
the
committee
for
this,
but
advocated
that
any
feature
that's
added
by
tc39
would
would
use
a
dedicated
js,
colon
prefix
and
any
other
feature,
that's
added
by
anybody
else,
whether
it
be
a
a
private
feature
added
by
a
particular
organization,
company,
whatever
or
a
feature,
that's
added
by
a
standard.
C
A
B
Go
ahead.
Mark
okay,
I
think
that
them
saying
that
they're
willing
to
support
the
feature
was
not
was
kind
of
empty
without
without
there
being
built-in
modules
that
are
available
as
built-in
modules
across
the
javascript
ecosystem.
B
They
understood
that
they
were
killing
javascript
defined
built-in
modules
you
know
hosts
are,
of
course,
free
to
provide
host
provided
modules
in
the
you
know,
host
provided
import
namespace,
that's
the
case
right
now.
Nothing
that
happened
would
change
that.
So
I
I
didn't.
I
didn't
take
any
words
of
support
as
anything
other
than
empty,
given
the
rest
of
what
they
were
saying.
C
Yeah
and-
and
I
I
took
that
as
the
same
you
know-
I
made
it-
there
was
a
lot
of
offline
discussion.
We
found
out.
The
google
in
mozilla
is
willing
to
willingness
to
block
about
a
three
days
before
the
meeting,
and
there
were
some
offline
conversations
before
that.
Before
the
presentation,
I
made
it
very
clear
that
I
didn't
view
this
as
a
science
project.
C
This
was
intended
to
be
value.
Add
to
the
language.
A
I
feel
also
feel
that
relevant
to
bringing
a
solution
to
built-in
modules
to
the
committee
again,
if
we
were
to,
if
among
among
apart
from
the
the
reasons
that
the
issue
that
the
proposal
was
blocked
this
time
along
the
way,
it
became
clear
that
there
were
some
that
that
one
of
the
one
of
the
things
that
was
we
were
asked
for
was
a
solution
that
that,
for
one
it
had
to
be
shimmable
and
I'm
hoping
that
compartments
can
answer
that.
But
it
also
a
harder
harder
issue.
A
Is
that
any
any
functionality
that
the
language
provided?
They
want?
The
parties
parties
on
tc39
wish
for
those
to
be
available
not
just
to
modules
but
also
to
program
scripts,
and
that
that
and
the
bulk
of
michael's
proposal
for
this
round
was
addressing
those
concerns.
B
Yeah
and
I
think
compartments
if
we
start
with
compartments,
we
end
up
actually
addressing
those
concerns
in
a
cleaner
manner,
cleaner
and
less
powerful.
But
now
that
built-in
modules
are
off
the
table,
that
less
powerful
thing
becomes
our
own
option,
which
is
that
the
you
still
have
to
have
the
shimming
and
set
up
code
running
in
an
earlier
phase.
B
You
have
to
be
running
in
one
compartment
in
order
to
create
a
you
know,
in
order
to
set
up
the
environment
for
creating
a
new
compartment
in
which
the
the
scripts
that
can
directly
use
built-in
modules
are
the
equivalent
to
built-in
modules
with
shimmed
modules
are
then
in
the
secondary
compartment,
because
they
can't
be
in
the
the
original
compartment,
because
it's
too
late
for
the
original
compartment,
and
I
think
that
that's
a
fine
answer
for
javascript
what
that
answer
means
with
regard
to
scripts
embedded
in
html,
which
was
part
of
what
was
motivating
a
lot
of
the
complexity
or
a
lot
of
the
is,
you
know,
still
still
to
be
worked
out,
because
it's
that's
that's
one
where
we're
crossing
standards
organizations
but
as
far
as
javascript
itself
is
concerned.
B
D
If,
if
the
consensus
is
that
the
committee
will
continue
adding
features
as
a
global
intrinsic
or
reference.
D
Right
so
if
they're
saying
that
that's
the
consensus,
then
what
is
going
to
be
left
for
built-in
modules
to
provide
access
to
what.
B
C
I
I
think
it's
it's
pretty
clear.
We've
mentioned
this
many
times
that
some
kind
of
of
of
library
system,
besides
globals,
was
needed
in
the
language
you
know
15
years
ago.
So
you
know
we
were
late
late
to
the
game.
Although
we're
not
the
first
proposal
that
tried
to
do
something
like
this.
I
think
there
is
the
belief
on
the
committee
by
some
that
well,
we've
gone
this
far
and
there
hasn't
been
any
problems,
any
showstopper
problems.
C
Why
do
we
expect
that
to
be
problems
in
the
future,
and
I
think
that
that's
a
little
naive
but
but
that's
an
opinion
and
different
people
will
come
down
different
ways
on
whether
or
not
that's
a
valid
concern
or
not.
B
I
think
I
think
the
one
inhibition
that
we
should
all
practice
is
that
adding
adding
new
standard
functionality
to
the
global
namespace
by
adding
new
global
names
is
expensive.
Real
estate,
in
the
same
sense
that
adding
new
syntax
is
expensive.
Real
estate
is
less
expensive
than
new
syntax
still,
but
it's
much
more
expensive
than
adding
new
modules
to
a
built-in
module
namespace,
and
we
just
need
to
always
raise
awareness
of
that
in
committee.
B
As
you
know,
you
don't
get
to
add
a
new
global
variable
unless
it
really
pays
for
its
weight
and
and
that
we
we
all
stay.
You
know
we
all
exercise
some
some.
You
know
some
taste
with
regard
to
whether
the
human
factors
cost
of
an
additional
global
variable
name
is
worth
the
functionality
that's
being
added,
and-
and
we
don't
just
let
it
be
a
free
for
all.
B
Okay,
so
it's
a
good
question.
One
quick
answer
is
that
with
different
hosts
providing
host
provided
mod,
you
know
built-in
modules
host
provided
modules
in
the
import.
Namespace
compartments
allow
javascript
code
on
one
host
to
emulate
the
javascript
environment
that
would
be
seen
on
another
host.
So
the
host
virtualizability
with
regard
to
initially
available
modules,
is
still
still
enabled
by
compartments
and
then
once
that's
entrenched,
then
you
know
once
basically
once
compartments
are
something
people
accept
as
part
of
the
language
going
forward.
B
A
I
think
that
I
can.
I
can
say
that
I
see
where
kuriti's.
I
think
that
kiriti
is
saying
is
that
the
requirement
that
anything
that
the
language
provides
must
be
available
both
to
programs
and
to
modules
and
and
that
that
is
that
that
stance
is
incompatible
with
the
idea
of
it
implies
that
everything
must
at
least
must
be
accessible
from
globals
as
a
basis
and
then
so
there's
not
much
of
a
value
add
once
on
once.
A
You
once
you've
provided
an
api
for
a
feature
as
a
global
that
reduces
the
value.
Add
for
also
providing
it
as
a
built-in
module,
and
to
that
I
think,
compartments
do
not
provide,
do
not
provide
an
answer
and
that,
if
built-in
modules
are
going
to
make
progress
as
as
a
feature
of
the
language,
if,
if
the
language
wishes
to
expose
its
standard
library
is
built
as
as
built-in
modules,
that
requirement
would
need
to
be
relaxed.
D
Right,
that's
exactly
what
I
was
trying
to
say.
Yes,
so
I
see
I
see
things
that
we
could
do
or
I
can
imagine
things
that
we
could
do
to
try
to
maybe
set
up
the
stage
for
in
the
future,
revisiting
the
built-in
modules
like
something
like
okay.
Well,
this
is
a
global.
The
mile
might
not
be
there
depending
on
certain
conditions,
and
you
could
move
it
into
a
built
in,
rather
than
have
it
into
a
global
in
certain
environments
and
so
on,
but
that's
just
hazard
for
developers.
They
need
to
figure
out.
D
Where
are
they
going
to
get
this
thing
from
the
built-in
or
from
the
global
and
what?
If
they
don't
have
a
way
to
get
it
from
the
buildings
and
so
on?
But
I
I
feel
that
the
compartment
is
not
really
providing
any
anything
new
that
will
help
the
cost
of
getting
built-in
modules
into
the
language.
I
don't
think
it's
it's
going
to
help
in
a
significant
way.
D
B
It
it
provides
one
fundamental
thing
which
is:
it
gives
us
a
different
and,
I
would
say
more,
principled
way
to
handle
the
shimming
problem,
which
is,
if
you're
starting
on
a
platform
with
a
earlier
set
of
built-in
modules
and
you're
trying
to
emulate
a
later
set
of
built-in
modules,
rather
than
doing
doing
it
by
modifying
some
global
state.
B
You
do
it
by
by
creating
a
new
compartment
that
emulates
the
new
environment
and
then
running
the
code
that
should
see
the
new
environment
under
the
created
compartment.
So
it
basically
provides
a
staging
answer
rather
than
a
modifying
place
answer
or
for
shimming,
and
I
don't
and
whether
that's
enough
of
an
improvement
to
make
a
difference.
I
don't
know,
but
it
certainly
is
a
difference.
C
I
think
we
need
to
be
cognizant
that,
whether
or
not
we
think
that
we
have
a
better
way
of
providing
it
and
there
still
may
be
some
pushback
to
of
having
modules
built-in
modules
in
the
language
anyways.
So
I
am
not
under
any
kind
of
illusion
that
this
makes
the
path
easier
to
acceptance.
C
B
Yeah,
that's
so
that's
another
thing,
so
by
the
time
we
revisit
this
by
the
time
we're
prepared
to
revisit
it,
the
ecosystem
may
have
changed
to
where
people
see
the
browser
as
less
unilaterally
dominant
over
the
rest
of
the
ecosystem,
and
people
are
see.
Modules
as
relatively
more
important
and
scripts
is
relatively
less
important.
That
all
could
happen
by
the
time
we're
set
up
to
revisit
this
yeah.
That
one
day
I.
E
Mark
I
I
believe,
you've
been
too
optimistic.
I
I
like
that,
but
I
started
to
tend
to
agree
with
michael
here
in
some
sort
of
I'd
like
to
give
some
feedback
on
what
I
see
on
the
beauty
modules,
because
I
think
there
is
a
perception
that
I
see
here.
There
is
slightly
different.
I
kind
of
agree
with
all
the
other
reasons
like
why
beauty
modules
was
blocked
at
this
meeting,
but
I
think
there's
a
lot
of
much
more
like
political
concerns
over
governance
for
beauty
modules.
E
Governance
was
even
a
word
that
was
used
for
those
blockers
and
well,
I
think,
like
the
sentiment
is
still
like.
Yes,
people
could
we
could
still
use
tc39
to
ship
something,
and
I
think
even
we
could
even
get
more
people
on
board
saying
we
could
ship
some
things
in
as
beauty
modules
as
I
do.
I'm
totally
positive
about
beauty
modules
as
it
was
proposed,
but
I
I
think
that
the
the
problem
of
people
blocking
are.
They
are
not
really
much
into
the
concerns
of
interoperability.
E
They
still
want
the
beauty
modules,
but
it
just
worked
for
what
what
works
for
them,
but
not
in
across
platform
sentiment
as
like
things
that
work
in
a
node
or
multiple
or
even
beyond
that.
E
So
I
think
there
is
much
more
like
a
of
a
political
problem
than
any
technical
aspect
of
beauty
modules,
and
I
I
feel
it's
a
bit
naive
to
believe
compartment
will
actually
get
some
of
those
problems.
So
while
we
still
have
these
big
politics
for
political
blockers
in
game.
B
Yeah
the
but
the
the
those
political
blockers
are
a
matter
of
I
mean
that's.
The
kind
of
of
you
know,
balance
that
shifts
over
time.
So
you
know
if
we
let's
say
a
year
from
now
with
you
know,
compartments
all
solid
and
accepted
and
entrenched.
B
A
We're
a
little
bit
over
a
time
box,
yeah
leo,
I
would
want.
I
wanted
to
give
you
an
opportunity
to
talk
about
progress
on
realms
on
the
record.
E
Well,
in
my
case,
it's
more
just
like
updates,
but
not
really
something
like
that.
I
wouldn't
mind
if
we
want
to
extend
with
beauty
modules
to
be
pre-honest,
and
I
can
use
next
week
for
realms.
B
Okay,
chris,
why
don't
you
go
into
your
presentation.
A
Okay,
all
right
so
take
two.
I
will
try
to
get
through
the
slides
rapidly.
A
Present
all
right
recap
talking
about
sex
proposals
and
where
they
are
and
where
we
need
them
to
be.
At
the
moment,
we
have
a
few
sources
of
truth.
There's
the
specification
proposals
which
are
stale,
the
excess
implementation
and
the
session
implementation,
which
have
somewhat
diverged
and
and
also
are
focused
on
different
dimensions
of
the
problem
and
I'll
talk
more
about
that
and
then,
of
course,
our
documentation
and
then,
of
course,
our
aspirations
which
differ
from
all
of
those.
A
So
this
is
going
to
be
a
bit
of
a
recap
of
how
we've
diverged
proposals
to
converge
and
some
proposals
to
to
go
beyond
what
is
implemented
or
specified.
As
well
recap:
cess,
we
are
reframing
the
cess
proposal
as
an
we
have
an
aspiration
to
reframe
the
sas
proposal
as
an
umbrella
for
for
security
or
integrity.
A
Related
proposals
with
our
prior
successes
on
the
left
are
aspirations
on
the
right
and
how
to
break
them
down
like
realms,
lockdown,
harden
and
then
layering
compartment,
so
that
we
provide
as
much
value
as
possible
with
with
with
motivations
and
stages.
A
Instead
of
proposing
one
big
pill,
then
just
recap:
we
we
had
previously
focused
on
a
realm
centric
set
story,
which
is
what
our
documentation
reflects
today
and
we're
moving
toward
a
compartment-centric
story
where
we
can
have
integrity
within
a
realm
and
then,
where
we
stopped
last
time
was
discussing
the
shape
of
the
lockdown
api,
and
so
the
way
the
lockdown
api
is
shimmed.
Today
is
that
it
introduces
the
compartment
constructor.
It
introduces
the
harden
function
and
the
harden
functions
initially.
A
Inert,
because
we've
discovered
that
harden
is
not
a
harden,
is
dangerous
and
and
not
useful
to
use
before
lockdown
and
provides
no
security
guarantees
until
after
lockdown,
so
we've
simply
forbidden
it
until
lockdown
has
been
called.
A
Then
lockdown
itself
is
something
that
the
user
may
call
later
at
their
leisure,
which
repairs
the
intrinsics,
including
notably
also
the
compartment,
which
is
which
is
now
somewhat
orthogonal
to
lockdown
in
the
in
the
same
way
that
function,
constructor
is
orthogonal
to
lockdown
and
then
lockdown
erases,
the
intrinsics
and
then
hardens
them
erases,
the
unallowed,
intrinsics
and
hardens
them.
A
Last
week
we
discussed
moving
things
around
so
that
the
erasure
occurs
earlier
during
the
repair
phase,
so
that
so
that
shims,
which
we
would
hope
to
introduce
between
repair
and
lockdown
in
a
future
version,
would
have
an
opportunity,
would
see
the
progressively
growing,
see
the
environment
progressively
grow
from
where
they
start
at
the
end
of
repair
and
then
augment
the
white
list
or
allow
list
according
to
what
they
add
to
the
environment,
which
provides
a
potentially
better
user
experience
for
shim
developers
and
allows
us
to
detect
errors
in
shims
earlier,
but
does
not
does
not
eliminate
the
need
to
express
the
intrinsics
and
the
allow
lists
as
separate
globals,
which
was
a
concern
that
kurditi
brought
up
last
time
two
weeks
ago
that
we
still
have
not
found
a
way
to
not
to
do
so
go
ahead.
A
Chip
says
harden
is
inert
until
lockdown
will
throw
an
exception
if
used
before
lockdown.
If
it's
gonna
throw
an
exception,
I
wouldn't
call
that
inert
fair,
all
right.
Yeah
inert
is
a
term
that
we
started
using
in
the
implementation
for
the
inert
function,
constructor,
which
is
the
the
the
constructor
of
on
the
shared
prototype
that
throws.
If
you
attempt
to
use
it
to
cons
to
to
use
it
as
an
evaluator
in
a
place
that
it
can't
be,
we
can
revisit
the
name.
A
Yes,
there's
no,
it
means
no
op
yeah.
I
get
that
well
well
back
to
the
drawing
board
on
that
one.
It's
fine!
We
can.
We
can
revisit
that
the
so
allowed
properties
and
intrinsics
there
were
so
in
the
in
the.
So
we
have
an
untold
story
for
when
we
do
have
support
for
shimming
in
the
lockdown
proposal.
A
How
do
we
express
the
allow,
the
the
allowed
properties
and
the
intrinsics-
and
there
are
some
open-
there's
an
open
design
space
for
it
for
this
at
the
moment,
the
internal
implementation
being
unconcerned
with
what,
with
the
the
ergonomics
of
the
api,
because
it
does
not
need
to
expose
them
to
the
user,
makes
certain
accommodations.
A
It
uses
a
a
doubly.
It
uses
essentially
a
json
structure
for
the
for
the
allow
for
the
allow
list,
but
because
it's
using
a
json-like
structure,
it
needs
to
accommodate
special
names
so
that
it
doesn't
confuse
dunder
proto
for
the
object,
actual
dunder
proto,
and
we
need
to
be
able.
So
we
use
this
bracket
notation
from
the
current
or
a
previous
specification
mark
correct
me.
A
If,
whichever
one
it
is
we're
using
notation
from
the
current
or
previous
spec
in
order
to
disambiguate
the
object
protocol
in
that-
and
that
is
perhaps
something
that
we
would
not
want
to
expose
to
users.
But
it
may
prove
to
be
practical,
given
that
it's
very
unlikely
that
the
allow
list
would
need
to
express
express
names
that
actually
do
contain
these
special
characters
and-
and
we
could
also
explore
an
alternate
imperative
api,
for
example.
A
Allow
allow
property,
like
a
lockdown.allowed
property
method,
to
to
to
say
that
this
is
something
that
should
be
retained
after
after
lockdown
harden
currently
fails,
if
the
pro
pro,
if
if
the
prototype
of
a
hardened
object,
is
not
itself
hardened,
which
has
turned
out
to
be
a
bit
of
an
ergonomic
problem
for
our
hardened
art
when
to
be
clear,
harden
is
a
function
that
transitive
that
guarantees
that
the
object
that
it's
passed
is
is
transitively
frozen.
That
is
to
say
it's.
A
It's
all
of
the
properties
accessible
transitively
on
the
objects
of
the
of
the
given
object
are
themselves
frozen,
and
it
does
that
behind
the
scenes
by
keeping
track
of
what
it
has
already
hardened
so
that
it
can
short-circuit
in
the
cases
where
it's
already
seen
an
object.
The
current
implementation
and
and
therefore
the
basis
for
any
proposal
that
we're
about
to
write
stops
at
the
prototype.
So
if
it
finds
that
the
prototype
of
an
object
has
not
been
hardened,
it
just
throws
an
exception.
A
The
reason
for
this
being
that
the
reason
for
this
being
that,
if
we
were
using
harden
that
hardened
was
invented
in
the
era
when
we
were
talking
about
using
realms
as
an
integrity
boundary
as
our
as
our
primary
story
about
using
it
as
an
integrity,
boundary
and
harden,
it
is
not
desirable
for
harden
to
transit,
a
realm
boundary
and
then
into
a
realm
that
has
not
been
locked
down,
and
our
conclusion
at
the
moment
is
that
that
is
better
served
with
a
distortion
on
the
membrane
between
the
realms.
A
That
would
cause
the
local
view
of
the
foreign
realm
to
appear
to
be
hardened
without
necessarily
transiting
that
boundary,
and
we
feel
that
we
can
simplify
the
hardened
api
from
a
user
from
the
user's
perspective
by
making
it
so
that
harden
is
simply
transitively
freezing
also
up
the
prototype
chain.
A
D
Go
ahead
before
getting
into
this
one:
do
you
happen
to
have
a
an
example
of
constructing
a
compartment,
repairing
it
lockdown
and
huddling
in
the
proper
order,
with
examples
of
the
kind
of
allowed
listing
that
you
will
have
to
do
and
so
on?
So
it
would
be.
It
would
be
good
to
get
an
example
to
visually
see,
yes,
maybe
having
an
issue
as
well
of
those
those
steps.
A
D
A
Details
at
the
moment,
we
don't
even
have
a
prototype
for
what
I'm
proposing
it's
it's,
but,
yes,
we
should
track
an
issue
and
we
should
come
up
with
an
example
shim
one
and.
D
A
Yeah
we
could
control,
we
could
come
up
with
a
sketch
of,
for
example,
taking
the
the
the
the
ansi
colors
shim,
which
monkey
patches
the
the
string
prototype
and
while,
while
we
certainly
wouldn't
advise
a
frivolous
use
of
of
of
the
colors
packaged
as
a
shim,
it
does
make
a
a
concise
example
of
what
wouldn't
be
necessary.
B
That's
a
really
nice
example.
I
like
that,
a
a
more
substantive
thing.
That's
that's
much
worse
as
an
example,
as
an
expository
example
is
a
bit
of
something
that
I'm
involved
in
right
now
is
shimming.
The
error
stack
proposal,
which
right
now
is
not
being
done
as
a
shin
and
it's
being
done
as
a
built-in
repair,
because
we
don't
have
the
the
full
shimming
support
in
place
yet.
But
I
would
like
to
move
much
of
that
into
being
a
shim
rather
than
being
built
into
a
lockdown.
A
The
motor
the
motivation
for
this
topic
of
of
shimming
on
lockdown
is
actually
very
much
that
we
have
already
discovered,
as
I'm,
about
to
present
about
the
compartment
opportunities
to
layer
shims
within
the
lockdown
and
and
then
eject
them
from
the
session
entirely,
so
that
we
can
create
so
that
users
can
pay
as
they
go
and
understand
them
in
separate
layers,
which
also
has
very
nice
properties
for
understanding
these
layers
from
a
security
perspective
because,
for
example,
compartments
have
have
many
facets
right
from
and
many
use
cases
and
the
simplest
and
earliest
proposals
for
the
compartment.
A
Api
are
just
compartments
as
evaluators,
and
that
provides
a
solid
security
foundation
for
building
all
of
the
subsequent
layers.
Such
that
the
layers
below
it
are
are
not
responsible
for
ensuring
those
guarantees
anymore.
A
So
the
many
facets
of
of
compartment,
the
base
layer
of
the
compartment
proposal
that
most
of
us
are
most
familiar
with,
is
just
an
object
that
has
an
evaluate
method
that
can
evaluate
source
inside
of
a
container,
and
this
is
the
this-
is
the
sufficient
value
foundation
for
being
able
to
evaluate
programs
inside
of
a
container
after
lockdown
and
the
end
that
that
layer
gives
us
the
ability
to
provide
to
endow
those
compartments
with
limited
additional
globals
above
those
that
are
just
granted,
as
as
the
intrinsics
that
provided
by
the
language
and
then
there's
a
layer
atop
that
which
is
the
I
which
I'd
like,
which
colloquially
is
the
xs
layer,
which
is
a
compartment
as
a
vessel
for
compiled
modules
and
in
this
world
the
xs
world.
A
The
only
the
only
modules
that
you
get
in
an
application
are
those
that
were
compiled
into
the
into
the
binary
they
serve
in
a
similar
way.
They
have
similar
capacity
to
the
built-in
modules
that
we've
discussed
before
and
in
this
world.
The
use
of
the
compartment
constructor
is
to
to
successively
attenuate
compartments.
A
So
you
would
be
able
to
say
I
I
have.
I
have
in
my
compartments
module
identifier,
name
space,
all
of
the
built-in
modules
that
that
they're
all
of
the
modules
that
there
are
or
ever
will
be
in
my
application
and
then
create
a
compartment
within
a
compartment
that
receives
a
limited
subset
of
those
compartments
by
name
and
the
compartment
has
the
ability
to
execute
those
modules
synchronously
because
they
do
not.
There
is
in
this
world.
The
compartment
constructor
is
not
a
loader.
A
A
A
But
we
have
been
focusing
on
the
compartment
as
a
module
loader,
an
asynchronous
module
loader,
and
at
that
layer
it
introduces
the
need
to
provide
module,
specifier
resolution
and
load
and
module
loading
as
hooks
and
at
that
layer.
It
is
sensible
for
there
to
be
a
load
method
that
that
that
uses
these
two
hooks
in
order
to
build
out
a
module
graph
that
the
prior
layer
would
be
able
to
proceed
from.
A
A
It
isn't
just
about
limitation
as
well,
it's
possible
in
excess
to
have
all
the
module
text
for
every
module
in
your
in
your
root
compartment,
but
not
be
able
to
link
them
because
their
relative
module
identifiers
do
not
make
sense
in
that
compartment,
and
you
need
to
alias
them
into
a
child
compartment
in
order
for
them
to
be
mutually
linkable,
which
is
a
detail
we
can
discuss
in
the
future
and
then.
B
Go
ahead,
one
thing
that
confuses
me
on
the
slide
is
twice:
you
have
just
a
simple
dot
as
a
specifier,
and
I
don't
know
what
you're
trying
to
to
come
to
convey
by
using
just
a
dot
as
a
specifier.
A
I
see
that
is
a
convention
in
the
the
the
dot
is
an
alias
for
the
main
module
in
the
node.js
packaging
convention.
I've
only
used
that
here
in
order
to
avoid
having
to
have
a
more
a
longer
name.
A
In
excess,
no
in
xs
you,
the
import,
now
comes
at
a
at
a
lower
layer
because
it-
and
it
does
not
have
a
load
method,
because
all
of
the
modules
in
excess
are
pre-compiled
into
your
binary
for
anything
on
the
web
or
anything
in
node.
Import
now
would
not
be
useful
without
load,
and
I
will
discuss
more
as
we
go
down.
A
I
have
a
proposal
that
import
now
itself
is
not
particularly
useful
on
the
specification
and
I'll
explain
why
later,
but
as
a
mental
model,
the
the
having
there
is
a
notion
that,
after
after
the
transitive
dependencies
of
module,
have
been
loaded,
it
is
then
possible
to
execute
them
without
any
further
loading.
And
that
is
an
idea.
That's
captured
very
well
by
the
name
import
now,
regardless
of
whether
it
continues
to
be
useful
in
practice.
D
Yeah,
my
only
suggestion
here
is
change
the
load
through
pre-load,
since
that's
the
term
that
we
use
them
in
browsers
and
maybe
even
the
node
by
preload
seems
to
be
a
little
bit
more
easy
to
digest.
A
Preloading
is
a
case
of
loading,
but
but
in
in
the
interest
of
time,
but
we
are
going
to
revisit
every
every
one
of
these
slides
at
some
point
in
the
future
and
let's
dig
into
that
then
and
the
so,
but
but
as
you're,
both
as
as
you've
pointed
out,
I'm
building
up
to
the
actual
use
case,
which
is
which
is
dynamic,
import
based
off
of
compartment,
which
is
built
on
top
of
load
and
import
now
or
preload,
and
import
now
and
go
ahead.
E
So
chris,
I
I'm
sorry,
I
just
want
to
add
something
I
might
have
missed
this.
I'm
sorry,
if
that's
the
case
but
but
for
import
now
and
load
whatever,
regardless
the
name.
It
seems
like
they're,
both
more
useful
as
like
serialized
methods,
rather
than
just
like
how
one
important
and
one
loading.
A
Oh,
I
see
yes,
the
in
practice,
there's
usually
a
single
entry
point
for
an
application.
It
is
certainly
possible
to
do
multi
to
to,
for
example,
promise
all
on
a
a
series
of
loads
and
then
and
then
and
then
opportunistically
import
them
the.
That
is
not
that
that
your
you
have
not
missed
anything.
I
have
not
proposed
such
an
api
for
for
loading,
multiple
things.
It
is
conceivable
that
load
could
be
very
attic.
A
Now,
an
import
cannot
because
of
the
signature,
load
returns
a
promise
for
undefined
and
it
would
compose
well
yeah,
okay,
so
so
the
plan
for
the
shim
is
for
us
to
stratify
it
so
that
there's
a
very,
very
small
lockdown
layer
that
contains
harden
pardon
that
the
shim
itself,
subsumes,
just
repair
and
lockdown
harden,
can
be
a
separate,
shim
or
or
or
consolidated,
that's
immaterial,
but
the
compartment
shim
is
orthogonal
because
it's
useful,
even
without
lockdown
and
lockdown's
relationship
to
the
compartment,
is
very
similar
to
its
relationship
with
the
function
constructor.
A
So
we
could
conceivably
layer
these
separately
and
that
may
make
the
compartment
shim
more
palatable
to
tc39,
because
it
is
effectively
the
missing
module,
loader,
api
and,
and
it
does
not
need
to
be
loaded
into
the
cess
gun
or
be
associated
with
with
sets
directly
in
order
for
it
to
make
progress
and
it
making
progress
is
helpful
to
ces
and
then
and
then
the
set,
and
then
the
but
the
compartment
shim
with
the
evaluate
layer
is
also
separate.
A
Separable
from
the
module
layer
and
the
module
layer
has
two
facets
to
it.
Itself,
one
part
of
it
which
is
sufficient
for
for
third-party
modules,
like
common
js,
js,
json
and
wasm,
but
is
not
sufficient
for
ecmascript
modules,
because,
at
least
for
the
perspective
of
the
shim,
it's
desirable
for
the
user
to
pay
as
they
go.
A
The
pay
for
what
they
need
and
and
being
able
to
do
esm
on.
The
shim
requires
entraining
a
full
parser
like
babel,
which
means
that
the
that
all
of
the
layers
above
esm
weigh
about
35,
kilobytes
minified
and
if
you
include
esm,
support
the
the
the
size
of
the
shim
blows
up
to
about
three
megabytes
and
in
order
to
make
it
practical
for
us
to
use
the
shim.
A
It
is
probably
possible
for
us
to
layer
this
in
a
way
that
that
the
minimal
evaluator
run
time
is
sufficient
for
as
as
a
compile
target
for
esm,
so
that
a
bundled
application
would
not
need
to
to
contain
that
parser.
So
this
this
is
the
direction
we're
kind
of
going
with
the
shim
for
implementation
related
reasons
and
also
somewhat
in
order
to
frame
it
in
a
way
that
makes
it
more
more
palatable
to
to
to
the
committee.
A
So
something
that
we
need
to
do
for
the
shim
is
convert
the
support
for
static
modules
into
itself.
A
layer
of
shim
which
we
can
only
do
after
we
add
shimming
support
to
lockdown,
and
the
idea
would
be
to
use
would
be
to
use
the
the
version
of
ces.
That
does
not
have
the
compiler
as
as
a
bootstrap.
A
So
here
thus
begins
the
six.
The
succession
where
I
propose
changes
to
the
shim
and
very
n
shimon
proposals
for
tc39
the
first
one
is
one
that
we've
already
implemented
in
session,
and
that
is
the
addition
of
a
name
to
the
options
bag
for
the
compartment.
Constructor
compartments
are
similar
in
spirit
to
functions.
In
this
way,
the
name
is
useful
in
the
implementation
for
surfacing
the
name
of
the
compartment
as
loader
errors
transit
up.
A
A
The
and
then
support
loading
without
executing,
so
the
as
I
mentioned
in
the
layering
that
there's
this
load
or
possibly
preload
method
on
the
compartment
that
is,
is
potentially
useful,
even
if
you
do
not
intend
to
eventually
import
because
this
can
be
used
in
tools
in
order
to
build
out
the
module
graph
for
an
application
for
either
the
static
analysis
of
that
graph
or
in
our
particular
applications
purpose,
to
build
an
archive
of
a
full
application
that
can
be
then
trans
and
then
shuffled
off
somewhere
else.
A
This
is
sort
of
spiritually
similar
to
to
using
browserify
or
webpack
and
and
having
a
load
method
on
the
compartment
api
and
a
module
method
in
order
to
in
order
to
express
linkage
between
compartments
at
the
at
the
same
layer
makes
it
possible
to
write
that
kind
of
application.
So
the
the
use
case
I
have
in
mind
is
the
compartment
matchup
mapper,
which
is
an
application
in
our
session
monorepo
that
uses
sas
in
order
to
emulate
node's
style
of
packaging
such
that
every
package
receives
it
has
its
own
compartment.
A
This
itself
is
a
foundation
layer
for
refactoring,
a
tool
like
lava
mode
from
metamask,
which
does
this
in
order
to
at
in
order
to
bring
esm
support
onto
on
into
lava
mode
and
and
what
lava
mode
does.
A
Is
it
attenuates
the
authority
of
every
compartment
based
off
of
static
analysis
and
and
policy
generation
such
that
third
party
packages
do
not
necessarily
have
access
to
all
of
the
built-in
modules
or
and
and
only
have
access
to
the
dependencies
that
they've
explicitly
declared
in
their
package
json,
which
I
think
is
also
a
big
win
for
developer
experience,
because
it
is
currently
possible
to
have
a
working
application,
while
still
forgetting
to
express
in
your
package
jason
what
your?
A
And
this
is
the
way
the
compartment
mapper
works
when
it's
using
load
modules,
the
apis
are
on
the
top.
We
have
an
import
location
method,
a
load,
location
right
archive,
make
archive
parse
and
load
and
import
on
archives,
and
the
way
it
works
is
that
in
the
base,
in
the
simple
case,
if
you're
just
importing,
if
you're
importing
an
application
off
of
the
file
system,
time
check,
I
have
five
minutes
for
you.
A
You
would
go
down
this
leftmost
workflow,
where
you
would
search
for
the
you
search
for
the
package,
json
that
contains
the
module
you're
trying
to
import
build
a
graph
of
all
of
its
compartments
by
searching
for
node
modules
in
the
in
parent
directories,
from
whatever
module
from
whatever
package
you're
in
and
then
assemble,
that
into
a
graph
of
compartments,
actually
constructing
those
compartments
and
linking
them
to
each
other
and
then
calling
load
and
then
calling
import
and
that's
that's
the
workflow
for
essentially
of
implementing
the
equivalent
of
node
and
that
module
name,
load
location.
A
Does
everything
of
that
except
not
executing
then
write
archive
does
all
of
the
same
things,
except
that,
instead
of
executing
it's
passing
its
own
import
hooks
that
allow
it
to
record
and
observe
what
was
loaded
in
order
for
it
to
satisfy
the
constraints
of
your
entry
module,
and
then
it
writes
those
it
writes,
whatever
it
loaded
into
a
zip
file
so
resuming
on
the
other
side.
You
can
skip
those
first,
two
steps.
A
A
A
We
create
the
parent
compartment
in
this
way,
passing
the
dependency
as
a
module
into
the
module
map
of
the
parent
compartment
and
then
giving
it
an
import
hook
so
that
it
can
load
so
that
it
can
load
modules
off
of
the
file
system
in
whatever
location
in
the
package
location
for
that
compartment,
and
then
you
call
load
and
then
you
could
call
import,
I'm
also
proposing
that
we
rename
import
hook
to
load
hook,
because
I
think
that
having
the
load
method
makes
it
clear
that
the
import
hook
is
not
subservient
to
importing
it
is
it
is
subservient
to
loading
and
and
that
you,
when
you're
loading
it
was
going
to
be
driving,
calls
to
the
import
hook
without
actually
importing.
A
I'm
also
proposing
that
we
add,
so
we
already
have
the
idea
of
a
static
module
record,
I'm
proposing
that
we
create
a
constructor
for
this.
That
takes
a
source
and
location.
This
doesn't
exist
in
the
proposal
yet,
but
is
an
obvious
need
for
esm.
A
I'm
also
proposing
that
we
introduce
the
ability
to
link
against
non-esm
modules
by,
in
addition
to
just
having
static
module
records,
also
having
a
static
module
interface,
and
this
is
just
an
object
that,
in
this
is
this
is
an
object
shaped
as
to
describe
its
imports
and
exports
and
then
provides
an
execute
method.
The
execute
method
would
receive
the
proxy
exports,
the
origin,
compartment
and
the
result
resolution
of
its
imports.
A
There's
a
typo
there
resolution
of
its
imports,
given
the
given
the
resolved
focus
given
in
the
compartment
in
which
it's
being
executed.
This
allows
us
to
do
common,
js,
json
and
wasm.
In
addition
to
esm,
but
noteworthy
about
this
is
that
it
is
not
able
to
model
my
times
up,
I'm
going
to
pause
here
and
revisit
next
time.
We
have
a
chance
that
sound
good.
A
Yeah,
I
think
your
presentation
suffered
from
rushing
a
bit
there
yeah.
Well,
the
idea
is
to
cover
the
material
and
then
revisit
so
we
can
break
this
down
into
topics
and
I'm
gonna
apology
for
the
rush.
B
How
much
how
much
remains
on
this
first
pass.
A
How
did
we
do
we
got
to
as
soon
as
I
find
my
window?
Oh
yeah,
it's
still
a
full
presentation
tab.
We
got
to
slide
21
of
32.
A
Sounds
good,
I
will
stop.