►
From YouTube: SES Meeting: Polishing Realms
Description
Leo Balter discusses Realms topics needed to build consensus for Stage 3.
B
B
B
And
after
some
discussions
and
in
order
to
make
this
re
becomes
reality,
we
ex
we
changed.
We
are
changing
the
text
with
the
new,
with
the
new
I'm
trying
to
cop
copy
this
for
request.
We
change
the
text
to
to
change
this
hook
to
now.
Also
now
we
actually
create
a
prohibition
for
any
properties
added
to
the
global
by
the
host
they
should,
they
must
all
be
configurable,
and
we
also
create
some
text
saying
they
should
have
no
authority
and
we
try
to
expand
some
text
in
there.
B
B
B
B
I'm
trying
to
avoid
that
this
is
being
distracting,
but
this
is
what
is
happening
right
now.
This
editorial
note
with
the
examples
I
just
make
sure
it's
actual.
It's
also
flagged
as
a
note
as
like
the
specification
does
not
recommend
any
specific
edition
in
the
web
and
embed
in
html
and
web
idl.
I
will
specify
which
interfaces
are
included
and
we
mostly
try
to
cut
off
like
io
features,
etc,
features
that
will
create
side
effects.
D
C
B
Yeah,
in
the
actual
paragraph
we
actually
say,
like
I'm
just
reading
some
part
here,
those
properties
must
each
be
configurable
to
provide
platform
capabilities
with
no
authority
to
ki
to
cause
side
effects
such
as
io
or
mutation
of
values
that
are
shared
across
different
realms
within
the
same
host
environment.
I
think
that
covers
that
mostly,
but
we
can
improve
it
because
not.
C
D
So
I
I
think
the
the
fact
that
these
are
all
specified
to
be
configurable
properties
also
gives
us
defense
against.
If
the
host
were
to
add
something
with,
you
know
shared
state
within
the
realm,
because
it
can
be
deleted
by
the
thing
that
creates
the
realm
instance
before
sending
it
to
application
code.
A
Yeah
on
that
note,
my
understanding
is
that
my
understanding
of
the
layering
of
the
architecture
of
these
proposals
is
that
realms
would
give
you
would
give
you
a
realm
like
that.
Is
it
would
give
you
a,
let
me
say,
loosely
immutable
realm,
like
the
like,
the
the
the
the
initial
realm
that
you
get
in
a
typical
javascript
environment
and
then
lockdown
would
propose
to
work
in
any
realm
to
turn
it
into
a
cess
environment
and
then
and
then
from
within
then
that
then
then
we
have
ces.
A
D
A
D
B
B
B
No
no
problem,
I'm
just
saying
like
we
are
actually
creating
a
restriction
on
what
was
allowed.
It
was
just
like
implicitly
low.
It
was
just
a
very
small
text
like
saying
it
was
allowed
like
it.
There
was
no
like
just
the
previous
text.
Just
worked
as
a
like.
A
fine
recommendation
like
we
don't
expect
properties
to
be
added,
but
not
expecting
doesn't
mean
like
we're,
disallowing
them
to
be
added.
D
So
so
part
of
the
idea
here
is
that
we
would
work
with
the
web
people
to
figure
out
which
globals
are
added,
but
the
exact
set
of
globals
would
be.
It
would
be
specified
in
the
web
standards,
not
not
in
javascript,
just
based
on
the
constraints
specified
here,
and
we
might
come
to
that
final
list.
After
stage
three,
we
wouldn't
necessarily
block
stage
three
on
all
the
host
integration,
just
on
making
sure
that
we
have
the
the
basis
set
up.
B
My
hope
for
this
is
to
be
able
to
experiment
realms,
regardless
of
like
a
final
definition
of
these,
these
global
properties.
So
we
can
have
like
tests
running
everything.
Hopefully
we
might
be
able
to
have
realms
under
a
flag
before
we
have
all
the
global
definitions
and
we
make
sure
like
it's
available
and
then
we
can.
We
can
play
with
these
restrictions
of
globals
that
can
be
removed
or
they
or
web
standards
defined.
They
need
to
be
added.
B
D
C
Is
that
just
like
the
ecmascript
standard
sites
unicode
a
particular
version
of
unicode,
without
including
a
copy
of
unicode
or
getting
into
a
turf
war
with
unicode?
We
can
likewise
have
ecmascript
standardize
globals
like
url
and
text
encoder
decoder
that
really
are
cross-platform
and
authority
free,
including
hidden
state
free.
C
D
B
This
is
a
chicken
and
egg
problem.
I
think
in
this
case
we
get
a
better
strategy
if
we
add
this,
and
we
can
definitely
follow
up
like
with
first
with
a
tutorial
note
of
things
that
are
finally
added.
I
think
like
for
stage
four.
When
we
have
the
per
request
to
achieve
262,
we
can
actually
create
an
editorial
note
with
listing
what
the
web
web
platform
adds
and
like
we
cannot
have
this
text,
yet
we
just
like
assume
but
like
definitely
the
request.
A
I
think
that
it
might
be
acceptable
to
have
a
hybrid
approach
where,
where
the
the
text
that
the
norm,
the
normative
text
of
the
spec,
does
allow
for
the
existence
of
things
that
are
not
in
the
in
the
spec
within
constraints
like
you,
the
like
the
configurability
constraint,
because
that
is
necessary
for
a
realm
to
be
locked
down
possible
for,
but
but
also
to
say
in
262,
we
could
say
if
you
have
a
text
encoder,
it
must
conform
to
this
spec.
If
you
have
a
text
decoder,
it
must
conform
perspective.
A
E
In
that
case,
isn't?
Wouldn't
there
be
a
request
from
web
environments
to
have
access
to
some
apis,
such
as,
for
example,
worker
which
are
definitely
outside
of
what
we're
talking
about
authority
here,
but
that
would
be
required
and
especially
because
those
are
not,
they
cannot
be
put
behind
a
membrane
because
they
have
like
special
capabilities
such
as
transferring
and
disconnecting
objects.
E
E
For
example,
a
worker
when
you
you
can
pass
array
buffers
through
them
and
transfer
them
or
shared
array
buffers
and
have
them
shared.
You
can't
do
that
through
a
membrane
between
realms,
so
you
wouldn't
be
able
to
membrane
the
worker
api.
You
would
have
to
have
it
natively
exposed
inside
the
realm.
B
E
B
B
We
have
a
polyfill
like
that.
I
just
don't
feel
ready
to
show
up
in
this
presentation.
I
worked
on
something.
Rick
did
a
lot
of
extra
work
to
to
bring
it
up
here,
but
I
just
don't
I
I
don't
want
to
show
it
up
here,
because
it's
too
early
then
next
week
I
I'll
show
up
something
with
next
week.
It
might
be
limited
on
the
import
part
because
of
like
reality
cannot
bring
me
a
true
import
experience
unless
I
actually
hacked
the
browser
code
but
like
if
we
use
the
evaluate
parts.
C
B
B
So
yeah,
this
is
one
of
the
things
that,
like
it's
hard
for
me
to
answer
how
it's
going
to
work
it's
right
now,
the
the
the
realms
they
are
doable
for
most
use
cases.
I
know
like
the
the
shift
we
we've
made
from
the
previous
realms
that
gave
like
full
global
disk
capabilities,
full
access
to
the
global
disk.
To
now
this
one
that
is
with
within
a
callable
boundary,
it
limits
some
of
the
use
cases
and
we
definitely
need
to
explore
how
to
open
more
access
to
these.
B
I
think
one
of
the
things
within
this
rounds
api
is
that,
like
it
all,
it
still
allows
some
exploration
on
how
we
we
promote
more
access
for
cases
that
are
like
this.
One
of
them,
like
that,
I
haven't
implants
in
my
plans,
is
actually
like
providing
more
access
to
shared
array
buffer,
because
that's
definitely
gonna
hit
me
eventually,
and
we
definitely
need
to
to
make
sure
we
we
have
access
for
that,
but.
E
E
I
guess
transferable
things
are
special
yeah
in
the
sense
that
internals
the
objects
get
recreated
on
the
other
side
with
internal
slots
that
are
somewhat
linked.
I
I
don't
know
I'm
not
super
familiar,
but
I
I,
as
a
user
of
web
apis,
off-screen
canvas
and
some
of
those
are
things
that
message
channel.
All
those
things
are
things
that
can
be
transferred
between
javascript
execution
contacts.
D
Yeah,
but
I
I
really
hope
that
in
in
a
membrane,
it's
you
know
the
same
solution
as
everything
else
for
internal
slots
that
you
have
to
like
unpack
it
before
setting
it
to
that
method.
That
needs
the
original
copy
and
that's
like
one
of
the
core
functions
of
the
membrane
and
so
transferable
things
have
internal
slot
by
virtue
of
the
the
kind
of
interface
brand.
That
web
ideal
assigns
the
object,
the
platform
object
and
that's
you
know
it's
analogous
to
an
internal
slot.
E
E
A
A
I
think
that
I
think,
let
me
ask
mark
is:
is
it
fair
to
to
characterize
the
relationship
between
realms
and
lockdown
and
compartments
in
the
way
described
earlier
that
that
a
realm
does
not
provide
the
invariant
issues
we
that
we
for
assesses
purposes?
We
do
not
require
the
realm
to
provide
the
invariance
that
we've
talked
about
for
compartments,
particularly
the
the
restrictions
for
your
muted.
C
Thank
you
for
you're
you're
right
about
ces.
That
cess
does
not
require
realms
even
to
avoid
powerful
globals
right,
but
the
as
we've
seen
there
are
some
use
cases
for
capability
confinement
that
treat
the
that
in
which
you're
trying
to
confine
code
that
does
modify
primordials
and
therefore,
for
which
cess
is
not
a
solution
that
fits
and
for
those.
C
What
you
want
to
do
is
create
a
realm
and
have
the
realm
as
a
whole,
be
the
unit
of
confinement
and
where
you
know
bad
code
within
the
realm,
can
foul
its
own
nest.
But
the
realm
as
a
whole
can
only
interact
with
the
external
world
according
to
the
confinement
rules,
and
you
could
still
have
initialization
code
that
removes
things
from
the
global.
C
In
addition
to
the
existing
platform,
specific
realm
creation
apis
like
creating
an
iframe
right.
When
you
create
an
iframe,
you
get
a
new
dom
tree.
You
get
all
sorts
of
powerful
things
that
come
from
the
platform,
and
then
it
becomes
a
lot
of
work
to
to
to
to
throw
those
things
away
and,
if
you're
going
to
create
them
just
to
throw
them
away.
It's
a
lot
of
of
you
know
overhead
for
no
purpose
and
yeah,
and
it
also
creates
a
maintenance
problem
which
is,
as
tc39
adds,
globals
and
as
w3c
adds
globals.
C
D
C
C
D
Well,
do
we
do
we
want
to
link
this
fight
to
the
proposing
the
realm
api
to
stage
three
or
do
we
want
it
to
be
decoupled
from
that,
because
you
know
leo
and
I
have
been
really
trying
to
to
come
to
some
kind
of
agreement
with
web
platform
people
and
we
feel
like
we're
really
close,
and
I
personally
don't
want
to
start
another
fight
right
now.
If
we
can
avoid
it.
I.
C
Would
I
would
certain
okay
so
so
let
me
just
stipulate
that
I
certainly
think
we
should
avoid
fights
that
we
can
avoid
it's.
It's
always
good
to
post,
to
avoid
fights
or
decouple
fights
and
have
them
later
to
the
extent
that
we
can
without
compromising
our
goals,
so
the
the
so.
The
first
question
is
what
what
is
the
goal
of
providing
a
platform
independent
realm
api
standardized
as
part
of
javascript,
given
that
the
web
platform
already
has
a
web
platform
specific
api
for
creating
a
web
platform
specific
realm,
I.e
the
iframe?
C
C
C
D
D
C
C
Are
there
any
so,
it
sounds
like
having
adopted
the
no
shared
state
and
no
io
that
that
the
remaining
issue
with
regard
to
ocap
safety
is
the
no
hidden
mutable
state.
It
sounds
like
that's
just
an
over.
I
mean
from
what
I'm
gathering
from
this
conversation
is
that's
an
oversight
rather
than
some
web
platform.
People
having
some
particular
objects
that
satisfy
the
no
shared
state,
no
io,
but
have
hidden
mutable
state
that
they're
trying
to
advocate.
F
Well,
so,
actually
those
those
those
cases
are
interesting.
So,
like
no
io
calls
to
my
mind,
things
like
alert
and
confirm
which
I'm
not
sure
what
their
opinions
would
be,
but
I
suspect
omitting
them
from
realms
is
reasonable
and
then,
when
we
talk
about
hidden
states,
what
are
your
thoughts
on
set
timeout,
because
that's
the
one
where
I
think
it's
there's
there's
probably
there
might
be
an
argument
for
them
to
include
it
in
the
web
platform.
So.
C
F
C
So
so
I
think
that
so
let
me
say,
there's
two
cons.
There's
there's
two
consistent
points
of
view
that
that
that
I
think
we
can
take
to
this
one
is
that
as
long
as
everything's
deletable,
they
can
put
any
crap
there.
They
want,
because
we
can
delete
it
and
that,
as
as
chris
says,
that's
perfectly
consistent
with
everything
that
ces
needs,
because
cess
can
start
off
in
a
platform
realm
yeah.
F
C
F
C
So
so
cess
does
not
need
the
restriction
of
no.
I
o
no
shared
mutable
state,
but
that
means
that
if
you're
going
to
use
a
realm
as
a
coarse-grained
confinement
boundary
for
security
purposes,
you
do
have
to
have
that
initialization
code
to
remove
all
the
powerful
things,
and
it
means
that
you
do
have
this
maintenance
issue
of.
How
do
you
know
what's
powerful
or
not
if
the
global
was
added
after
you
wrote
the
the
code
to
remove
it.
A
D
D
C
C
It
could
follow
this
proposal
and
be
its
own
separate
fight.
I
don't,
I
don't
see
that
those
fights
have
to
be
coupled
because
right
now
we've
got
user
maintain.
You
know.
We've
got
white
lists
and
user
code
right
now
in
cess
in
the
session,
and
we
we
have
the
maintenance
burden
of
updating
those
as
the
platform
changes.
F
E
C
C
Like
you
know,
the
async
generator
prototype
is
one
that
we
actually
had
a
security
hole
after
async
generators
were
added
by
the
language,
and
our
internal
mechanisms
had
not
yet
been
updated.
You
could
access
shared
mutable
state.
I
mean
you
know
a
hidden
mutable
state
by
you
know
by
finding
those
by
syntax
which
we
had
not
frozen
when
we
froze
cess
so
having
a
white
list
of
all
that
at
least
includes
all
of
the
intrinsics
that
are
not
reachable
that
are
not
discoverable
by
property.
Walk
would
actually
be
a
wonderful
thing.
A
Indeed-
and
we
could
probably
actually
address
that
with
perhaps
a
language
invariant-
that
everything
that
is
that
is
producible
by
syntax-
should
be
discoverable
from
global
this,
which
would
have
prevented
that
problem
from
occurring
in
a
very
natural
way.
We
wouldn't
have
had
to
have
a
we
would.
We
don't
need
a
white
list
if
there
is,
if,
if
there
is
a
global
for
for
the
async
generator.
D
C
D
A
B
Sure,
sorry,
if
I'm
I
am,
might
be
interrupting
here,
but
I
think
we
have
like
12
minutes
left
and
I
still
have
an
update
on
the
modules
graph
just
want
to
give
more
space
to
that
discussion,
and
that
might
be
a
little
bit
more
actionable
excellent
for
this
meeting.
If
you
don't
mind,
I'm
sorry
yeah.
A
B
B
So
when
we
talk
about
module
graph
and
reuse
in
the
module
graph,
there
is
an
implementation
detail
of
what
they
have
for
modulograph.
So
from
my
understanding
with
shu
this
should
this
might
be
more
simple
than
we
are
also
expecting
for
this
fight
and
shu
told
me
they
would
be
satisfied
if
just
reusing
this
mo
the
same
modulograph
for
io,
but
actually
just
fetching
and
having
some
io
cached.
I
I
love
the
baby.
B
B
D
Yeah,
of
course
it
would
have
separate
linking
it
wouldn't
there's,
no
way
it
could
work.
Otherwise,
you
know
it
would
be
a
separate,
separate
source
text,
multiple
record,
but
maybe
that's
the
same.
Actually,
oh
someone's
typing,
maybe
it's
richard.
So
I
don't.
I
don't
know
exactly
what
the
proposed
resolution
is.
Honestly,
I
don't
understand
the
concerns
that
dominic
is
raising.
It
seems
like
shu,
agrees,
that
we
should
have
a
separate
evaluation
of
the
module
per
realm.
Otherwise
nothing
makes
any
sense
and
it
might
be
some.
It
may
be
potentially
an
editorial
change.
D
You
know,
in
the
case
of
import
assertions,
dominic
specifically
insisted
that
we
don't
cache.
I
o
so
I'll,
be
a
little
bit
surprised
if
the
solution
is
to
cache.
I
o
in
this
case,
but
it
may
be
an
editorial
change
as
simple
as
right.
Now,
there's
a
module
map
per
realm
and
instead
we
would
say
well,
there's
one
module
map
per
window
and
that,
like
contains
a
different
copy,
the
module
keyed
on
the
realm
like
keep
weekly
on
the
realm.
G
D
G
Already
do
that
effectively
in
node
on
our
vm
modules,
so
it's
certainly
possible.
Today
there
are
existing
bugs.
We
haven't
been
able
to
upstream
changes
to
allow
it
to
not
leak
memory,
and
so
I'm
wondering
if
this
is
kind
of
like
how
import
assertions
was
based
upon
the
html
specs,
specific
implementation
of
caching.
If
it's
the
same
there
that's
going
on
here.
D
Well,
this
you
know
the
realm
case
requires
more
things
to
be
weakly
held
in
the
import
assertion
case
because
in
the
import
assertion
case,
you
know
there's
just
so
many
different
things.
You
could
write
in
the
assertions,
but
in
the
realm
case
you
know
you
can
create
unlimited
realms
and
they
have
liveness
lifetimes
things
like
that.
G
D
G
B
G
Well,
the
won't
fix
we
got
back,
if
I
recall
was
that
they
don't.
So
when
we're
talking
about
module
maps,
there's
the
local
in
the
global,
the
locals,
they
were
fine
collecting
the
global.
They
wanted
to
be
persistent
in
case
it
ever
gets
reloaded
ever
and
there's
no
real
way
to
state
that
this
thing,
which
on
the
web,
is
always
able
to
forge
the
identity,
because
it's
stored
by
a
string
will
never
be
loaded
again.
G
That's
the
local
module
map,
they're
fine,
garbage
collecting
local
references,
but
the
global
map
is
always
keyed
by
string,
and
so
that
means
it's
forgivable
and
they
don't
want
to
deal
with
that.
They
didn't
want
to
make
it
so
that
it's
not
keyed
by
string.
So
when
we
generate
virtual
modules
in
our
vm
module
in
node,
we
actually
assign
them
a
string
always-
and
you
have
to
like
guard
against
forgery
of
the
string,
which
is
actually
rather
hard.