►
From YouTube: SES Meeting: Import Reflection and Compartments
Description
This week we met with Guy Bedford to identify the intersection between import reflection and compartments.
B
Today
you
have
instantiation
of
modules,
that's
done
imperatively
in
js,
they
all
require
unsafe
wasm,
involve
csp
policies
and,
in
addition,
you're
using
usually
fetch
to
get
this
module.
So
it's
those
those
problems
that
we're
kind
of
tackling
and
when
we
first
presented
the
proposal
of
some
of
the
feedback
works,
could
we
make
this
more
general
for
js,
and
so
we
were
saying
well
if
we
could
just
get
this
we've
seen
that
compartments
is,
is
starting
to
reflect
this
stuff.
B
Could
we
just
reflect
a
similar
kind
of
reflection
and
and
just
get
the
modular
reflection?
How?
How
far
does
that
get
us,
and
it
at
least
it
seems
to
be
a
really
nice
model
on
top
of
the
module
system
and
it'll
yeah
there's
already
this
double
module
map,
where
you
have
the
fetch
cache
and
the
instance
cache,
and
it
further
refines
that
pattern
in
a
way
that
we
really
have
to
refactor
the
specs.
B
And
so
those
were
the
kinds
of
discussions
that
I
was
hoping
to
be
able
to
explore
further
a
little
bit
more
in
collaboration
with
compartments
and
then,
as
I
say,
I'm
I'm
happy
to
dive
into
the
wisem
use
cases.
I
just
I
don't
feel
like
that
should
be
the
primary
focus.
But
this
discussion
necessary.
A
B
A
The
syntax
that
you
proposed
at
the
plenary
is
coherent
with
compartments.
I
think,
provided
that
the
ratification
of
the
ratification
of
a
module,
it
corresponds
to
some
com
concept,
some
specific
concept
from
the
compartment's
proposal,
that
is
to
say,
if
you
say,
import
thing,
with
name
from
a
wasm
module
with
annotations,
suggesting
that
it's
not
supposed
to
be
executed.
A
B
Yeah
and
potentially
dino
as
well.
They
they
kind
of
contract
that
at
a
certain
secure
level,
so
the
having
the
source
of
the
module
be
associated
with
the
module.
Is
that
is
that
really
important
thing
that,
like
it's
not
just
like
a
source
text
module
that
was
created
without
an
auditory
string?
But
we
know
it
was
defined
in
this
file,
which
was
fetched
through
the
module
system
at
this
resource
location
and
so
maintaining
that
tie
that
right
now,
all
scripts
and
modules
have
this.
B
You
know
associated
host
information
about
the
fetch
source
and
fetch
options
and
credentials
and
all
of
this
stuff,
and
to
have
that
that
direct
association
that
this
is
this
comes
from
an
original
place,
and
you
have
that
you
maintain
that
linkage
through
through
the
object-
and
I
don't
think
that's
actually
something
we
have
for
wiser
modules
at
the
moment.
So
it
would
be
interesting
to
explore
yeah
if,
if
we
could
get
a
western
record,
I
mean
I
was.
B
I
was
hoping
that
it
might
be
possible
to
to
thread
similar
information
for
wizard
modules
when
they're
imported,
because
I
believe
that's
what
would
be
involved
for
csp
integration
with
lyson
currently
in
the
sm
integration,
but
yeah.
That's
that's
worth
exploring
further
as
well,
so
that
the
object
that
you
reflect
associates
with
it's
with
its
secure
source.
It's
it's
important.
I.
C
C
D
Okay,
so,
and
that's
interesting,
because
that
also
yeah-
this
is
all
very
interesting
I've.
So
one
of
the
things
about
the
javascript
modules-
that's
that's
the
part
of
what
we
want
to
keep
you
know.
We've
we've
discussed
keeping
out
of
the
static
module
record,
but
putting
into
the
into
the
descriptor
is
also
the
support
for
the
import.meta.
D
B
D
B
A
While
the
proposal
to
reify
the
module
record,
shall
we
say
of
a
wasm
module,
including
the
static
and
dynamic
components
of
it,
is
coherent
with
compartments,
and
I
don't
object
to
it
being
added
to
the
language
on
that
basis.
There
is
another
mechanism
that
is
interesting
that
come
that
that
is,
that
potentially,
is
useful
for
this
case.
That
comes
from
the
compartment
proposal
as
as
as
written
right
now,
and
that
that
flows
from
excesses,
implementation
of
compartments,
which
allows
for
the
possibility
of
a
child
compartment
to
inherit.
A
A
It
might
not
even
need
the
host
compartment
to
have
pre-loaded
it.
It
might
like,
depending
on
whether
we
come
depending
on
what
we
decide
to
do
with
connecting
host
and
guest
compartment
loader
machinery.
It
might
be
possible
for
a
guest
compartment
to
just
pull
it
to
dynamically
and
asynchronously
pull
the
static
module
record
in
through
the
host,
which
I
think
is
important,
because
the
host
is
going
to
be
able
to
do
things
like
respecting
csp
and
and
implement
host
import
maps
and
such
so.
B
The
driving
use
case
here,
as
I,
as
I
say,
is,
is
the
fact
that
in
wasm,
these
modules
are
objects
that
you
want
to
get
a
handle
on,
and
you
wire
them
up
manually
and
link
them
with
with
custom
working
records,
and
it
is
a
priority
for
wasm
tooling
to
have
the
ability
to
be
able
to
do
this
in
a
way.
That's
secure,
because,
right
now,
it's
not
and
that's
the
driving
motivation
for
our
work
on
input,
reflection
and
our
generalization
to
js
is
simply
trying
to
make
it
more
architecturally
sound.
What
we're
doing.
A
So
that's
that's
useful,
like
being
able
to
express
statically
that
I
depend
on
the
thing
that
I'm
not
going
to
execute
is
necessary
in
the
bundling
case,
because
a
bundle
needs
to
be
able
to
close
over
all
of
the
transitive
dependencies
that
will
ever
be
needed
at
regardless.
Whether
of
whether
they're
executed
in
in
the
in
the
host.
B
Hey
that
is
sorry,
go
ahead
yeah.
I
just
wanted
to
add
a
couple
of
more
things
briefly
in
terms
of
the
interaction
with
compartments
and,
firstly,
based
on
feedback,
I
think
we're
not
going
to
approach
the
instancing
api.
I
think
it's
clear
that
that's
something
which
overlaps
too
much
with
compartments-
and
I
think
compartments
is
definitely
the
better
approach
because
of
the
unification
of
the
hook
model.
B
So
I'm
I'm
really
excited
to
actually
potentially
collaborate
more
on
some
of
those
compartments
things,
and
so
so,
thanks
chris
for
the
invitation
as
a
champion,
because
loaders
are
something
that
are
something
that's
been
important
to
us
for
a
long
time
and
see
seeing
the
where,
where
the
framing
has
got
to
is
it's
very
exciting
and
and
then
on
the
import
reflection
side.
I
I
think
it's
yeah,
but
just
just
about
working
out
how
we
can
collaborate
on
that.
D
A
B
E
I
believe
there
are
three
different
aspects
of
this
conversation.
One
of
them
is,
I
have
a
module.
I
would
like
to
import
something
from
awesome
module.
How
can
I
do
that?
I
believe
that
that
part
of
the
conversation
is
mostly
syntax
and
so
on.
So
I
don't
know
where
we
are
on
that,
but
I
hope
that
from
what
I
was
reading,
there
was
some
proposal
around
that
I
think
from
guy
and
george
fox
on.
E
E
That's.
I
hope
that
we're
also
looking
into
that
part
of
the
conversation.
We
need
that
kind
of
reflection
at
some
point
in
order
to
construct
those
modules
when
people
are
reporting
then,
and
so
on.
So
it
feels
to
me
the
web
component
is
very
convoluted,
obviously
I'm
behind
in
the
conversation,
but
if
we
can
focus
on
the
different
areas
and
clarify
the
different
areas
and
so
on,
it
might
be
easier
for
some
of
those
to
follow
up
on
the
equalization.
A
C
So
I
think
they're.
I
think
there
are
kind
of
two
possible
levels
of
service
that
we
could
provide
as
far
as
improving
integration
of
you
know,
the
wasm
component
model
and
asm
tooling,
with
with
javascript
so
one
the
base
level
is
so
that
tooling
can
get
by
while
having
you
know,
while
not
violating
csp.
C
I
think
that
might
be
satisfied
by
a
simpler
approach
with
a
function
based
api
rather
than
a
rather
than
a
statement
based
apf,
but
I'm
still
I'm
still
really
interested
in
module
reflection.
I
think
it
really
serves
this
kind
of
higher
level
of
service
where
we
are
working
in
conjunction
with
compartments.
C
Basically,
if
we
want
to
expose
the
wasm
component
model
to
javascript,
we
want
to
expose
kind
of
the
intersection
of
all
of
that,
then
it
would,
you
should
be
able
to
you
know
import
javascript
modules
without
instantiating
them
have
some
kind
of
instantiation
api.
I
like
the
idea
of
joining
forces
on
the
instantiation
api.
C
You
know
centering
on
compartments,
or
maybe
we
could
have
another
imperative,
instantiation
api,
but
we
would
have
to
like
understand
why
we
want
both
if,
if
module
reflection
is
building
towards
kind
of
the
second
one,
it
seems
it
seems
well
motivated
to
me
if
it's
focused
just
on
this
tooling
case
or
initially
on
this
tooling
case,
I
would
prefer
to
solve
the
initial
tooling
case
through
through
something
simpler.
I
don't
understand
why
the
tooling
would
need
to
participate
in
the
host
module
map
at
all.
C
Maybe
this
is
me
catching
up
on
the
requirements
that
tooling
is
given
so
far,
but
if
the
requirement
is
csp,
if
you
had
a
function
that
you
you
pass
in
a
module,
specifier,
slash,
url
it
fetches
it
and
does
compile
module.
You
know
with
the
system,
understanding
that
you
know
it
that
doesn't
call
wasm
unsafe
eval.
That
would
seem
sufficient
to
handle
this
only
tooling
generated
output
use
case.
E
C
Yeah,
so
I
think
they're,
you
know
they
could
definitely
work
coherently
without
compartments,
and
you
know
I
just
am
having
trouble
understanding
the
motivation.
I
was
able
to
follow
the
motivation
more
clearly
when
the
goal
was
this
broader
thing
that
would
have
compartments.
Otherwise,
I
guess
it
boils
down
to
kind
of
asset
references
for
wasm,
which
is
which
is
useful
and
the
main
thing
that
you
would
do
with
those
is
you
could
dynamically
import
them
later,
just
as
you
could
for
princesses
from
javascript.
C
Yeah
yeah,
I
feel
suspicious,
I
mean
I
feel
uncertain
if
the
motivation
is
boiled
down
to
like
okay,
the
real
only
motivation
is
for
tooling,
because
if
it
were
that,
then
I
think
there
would
be
other
approaches,
but
but
it
definitely
makes
sense
in
the
thinking
about
it
as
asset
references
that
you
might
use
dynamic
import.
You
know
with
host
import
maps,
not
import
maps
apps
on
or.
B
Page
references
to
things
in
the
import
system
that
have
certain
security
properties
or
security
resources
that
can
be
applied
and
yeah
the
assets.
One
is
kind
of
a
separate
discussion,
but
the
idea
was
that
there
could
be
another
reflection
for
assets,
something
like
the
assets
proposal
and
that
it
might
be
allowing
for
these
kind
of
things
as
well,
but
that's
also
kind
of
a
separate
discussion.
B
A
A
D
Yeah,
I
think
I'm
going
to
postpone
them,
because
I,
like
your
starting
point
better,
but
let
me
just
tell
you
sort
of
what
my
what
my
thoughts
were
in
terms
of
I
remember.
There
was
a
mike
samuel
proposal
to
tc39.
They
got
stalled,
but
had
very
lot
of
very
good.
It
was
in
order
to
support
c
various
csp
scenarios,
but
still
allow
eval
of
strings
from
trusted
sources.
E
D
E
D
So
our
descriptors
are
already
objects
that
can
be
branded,
and
it
seems
to
me
that
being
able
that
that
the
same
kind
of
host
hooking
could
also
say
that
I
will
accept
a
descript
descriptor
of
the
following
form.
Only
if
it's
branded
as
being
genuine
and
it's
just
a
question
of
being
genuine,
because
the
descriptor
itself
already
describes
where
the
thing
came
from
so
then,
if
it's
genuine
and
where
it
came
from,
is
acceptable
to
the
host
hook.
Then
you
know,
then
the
host
hook
could
decide.
A
Oh
yes,
and
the
other
way
that
the
other
way
in
which
this
is
coherent
with
compartments
is
suppose
that
we
take
the
guy's
proposal
for
module
reflection,
which
is
to
say
that
you
can
get
a
module.
Descriptor
object,
reified
from
the
host
environment.
You
could
pass
that
to
another
compartment
such
that
it
returns
it
from
its
load
hook
for
the
same
effect
right
so
yeah
in
your
in
your
host
compartment.
Let's
say
the
the
the
starting
realm
you
say:
import
module
from
module.wasm,
etc.
B
A
E
D
Okay,
so
so
guy
the-
I
don't
remember
the
the
specifics
of
how
it's
formulated
in
the
api,
but
if
I
recall
correctly,
when
you
instantiate
a
wasm
module
to
create
a
wasm
module
instance.
Besides,
providing
you
know
the
the
exports
to
bind
to
the
imports
in
order
to
hook
up
the
equivalent
of
the
the
you
know,
the
export
import
modulograph
relationships.
D
You
also
provide
a
memory,
an
array
buffer
for
the
memory,
and
you
provide
a
function
table
and
often
you
instantiate
many
modules
with
the
same
array
buffer
in
the
same
function
table,
but
you
can
provide
you.
Can
you
can
instantiate
with
distinct
memory,
buffers
and
distinct
function,
tables
and
still
link
them
together
into
one
overall
import
export
graph?
Is
that
all
correct.
B
Yes,
although
practically
what
ends
up
happening
is
that,
because
of
the
way
that
things
are
compiled,
you
end
up
with
just
having
one
memory:
protocol
module,
usually
anyway,
so
it's
very
rare
to
share
the
memory
buffers
and
instead
the
kind
of
yeah
the
convention
is
just
to
have
these
isolated.
They
end
up
just
being
isolated
environments,
despite
the
fact
that
you
could,
in
theory,
have
this
sort
of
shared
memory.
D
D
B
B
Interfaces
between
component
components,
communication-
which
which
is
would
be
really
interesting
if
that
could
feed
back
into
javascript
itself,
because
there's
some
really
interesting
work.
That's
being
done
to
define
all
these
interface
types
and
make
sure
that
you
can
get
the
expressivity
while
having
the
the
modularity.
D
So
so
is
it
consistent
with
all
of
this
to
have
where
you
would
have,
let's
say,
components
with
that
are
isolated
from
each
other?
Each
internally
have
multiple
modules
that
are
not
isolated
from
each
other
that
are
where
so
in
component
a
you
might
have
modules
x
and
y
that
share
their
instantiated
to
share
a
memory
with
each
other
and
then
component
a
is
linked
with
component
b,
where
component
b
has
modules,
p
and
q,
that
are
that
have
the
distinct
memory.
B
Right,
that's
that's
a
great
question,
so
what
you
would
usually
get
is
in
that
scenario
you
would
have
like
a
library,
only
module
which
is
just
functions
but
not
necessarily
memory,
and
you
would
import
that
module
as
a
source
of
basically
function
text
and
then
you
would
yeah.
Then
you
would
kind
of
be
reinstantiating.
Those
functions
against
different
memories,
so,
for
example,
you're
importing
your
malware
module
and
then
you're
instantiating.
All
of
your
different
components
against
this
shared
monolog
memory
and
and
yeah
you're
wiring.
Together
the
modules.
B
D
So
let
me
so
so.
This
is
all
great.
Let
me
let
me
let
me
sort
of
get
to
the
punch
line.
The
reason
I'm
raising
this
is
that
one
of
the
things
that
we've
struggled
with
with
regard
to
the
the
relationship
between
the
heart
and
javascript
interest
in
compartments
versus
the
module
integration,
the
purely
module
integration
and
margin
module
harmony,
interesting
compartments
is
are:
is
it
just
about
the
modules
and
module
loading
and
managing
import
namespace?
D
Or
is
it
also
about
what
global
object
is
the
module
instance
executing
its
code
in
the
scope
of,
and
it
seems
to
me
that
the
control
over
what
memory
is
given
to
which
wasm
module
instance
and
which
met
which
wasm
instantiations
share
a
memory
versus
which
ones
are
isolated
from
each
other,
is
directly
analogous
and
in
fact
more
than
now
like?
This
can
actually
be
mapped
onto
compartments.
B
Interesting
yeah,
I
mean
there
are
a
lot
of
that.
There
is
a
lot
of
cross-cutting
stuff
here,
because
they're
they're,
a
lot
of
it,
is
dealing
with
some
of
the
problems
of
isolation
and
security
and
instantiation,
and
things
like
that
in
general,
in
the
way
that
the
webassembly
semantics
are
today,
the
the
memory
is
instantiated
at,
like
usually
you
export
the
memory
and
it's
usually
instantiated
that
sort
of
execution
time
in
the
standard
case.
B
So
that's
why
it's
so
important
in
webassembly
to
have
a
handle
to
the
modules
so
that
you
can
create
a
new
you
can
create
this
new
fresh
environment
and
and
do
that
because
that's
exactly
what
you
want
to
do.
If
you
want
to
be
able
to
get
that
that
that
fresh
slate
and
so
yeah,
that's
that's
the
way
it's
been
specified.
B
Of
course,
there's
there's
a
million
ways
to
to
do
these
things,
but
like
yeah
I
mean
it's
also
worth
you
know,
I
think,
investigating
some
of
the
cross-cutting
stuff,
because
there's
definitely
interesting
conversations.
We
have
there,
but
at
the
same
time
we
are
where
we
are
today.
Web
assembly
has
an
imperative.
Instantiation,
api
and
js
has
a
declarative
one
and
they're
different.
It's
just,
however,
specified
it
wasn't.
You
know
if
we
could
go
backward,
we
have
done
it
that
way.
B
A
A
B
A
B
Point-
and
I
would
also-
and
then
one
of
the
things
that
I
really
love
to
achieve,
is
to
understand
for
the
import
reflection
proposal.
What
that
module
object
would
be
that
we
would
import.
And
yes,
I
would
really
appreciate
some
guidance
on
that
and
in
in
whatever
form
and
yeah.
I
hope
we
can
continue
that
discussion.
A
Yeah,
it's
sounding
like
from
our
conversation
yesterday
with
daniel
and
this
conversation
today
that
there's
a
placeholder
type
called
module
block
and
the
fragments
and
and
fragments
and
blocks
proposal
and
there's
a
module,
descriptor
type
in
the
compartments
proposal
and
there's
a
reflected
module
type
in
the
module
reflection
proposal.
These
all
may
be
the
same
thing,
and
the
good
news
is
that
it
is
small.
A
A
Yeah,
let's
come
let's:
let's
continue
this
conversation
I'll,
find
you
in
the
loader
talk
and,
and
we
can
coordinate
a
thing,
we're
loader
chat
and
matrix
and
we
can
coordinate
from
there
and
kiridi.
I
owe
you
an
hour
of
my
time
whenever
you
have
an
hour
of
your
time,
yeah.
Thank
you.
I'm
going
to
close
the
recording.