►
From YouTube: SES Meeting: Shadow Realm Errors
Description
Wherein we continue to discuss errors that cross ShadowRealms.
A
B
What
should
we
specified
or
what
should
not
be
specified
in
262?
Consider
that
the
error
properties
are
not
specified
today
that
in
combination
with
another
proposal
from
Matthew,
where
the,
where
we
make
very
explicit
normative
definitions
in
the
spec
to
prevent
objects
to
be
leaked
from
one
ROM
to
another.
That
seems
to
be
related
to
this
when
it
comes
to
error,
stack
and
the
name
of
the
error
and
the
message
of
there.
B
C
You
know
prepare
stack,
Trace
and
and
Associated
apis
that
have
this
structured
form
of
stock
Trace
that
contains
object,
references
in
particular
references
to
methods
and
references
to
the
this
arguments
of
the
calls,
and
so
the
and
and
therefore
the
prohibition
on
mixing
heaps
between
mixing
subgraphs
between
Shadow
Realms
would
apply
to
that
and
but
for
everybody
else,
and
for
perhaps
a
restriction
on
the
V8
thing
that
they
might
consider.
But
at
least
for
everybody
else,
there
is
no
object.
C
Sharing
that
happens
as
a
result
of
error.
Stacks
there's
only
information
share,
so
so
the
so
I
think
the
the
question.
So
there's
oh
and
then
there's
the
tactical
issue,
which
is
even
though
there
are.
There
is
no
error
handling,
there's
no
error,
Stacks
that
are
normative
in
the
spec
today
at
all
and
the
the
proposal
that's
in
Flight
is
I
think
still
stage
one
and
certainly
is
mostly
silent
on
everything
that
we
care
about
here.
C
The
real
open
question
for
us
is
what
it:
what
effectively?
What
advice
do
we
give
to
implementers,
because
all
the
implementers
have
some
kind
of
stack
and
even
though
the
stacks
have
no
normative
status,
they're
going
to
do
something,
and
in
order
to
implement
Shadow
Realms,
which
are
now
at
stage
three,
so
everybody
wants
to
implement
them
and
then
whatever
they
do,
Implement
with
regard
to
stack
handling
that
becomes
Legacy
that
we
then
cannot
break
without
breaking
the
web
after
that
point,
so
there's
there's
a
big
tactical
Mission
here.
D
C
B
And
and
the
counter
argument
that
we
have
for
that
and
I'm
in
the
other,
Camp
I
think
at
this
point
I'd
rather
prefer
they
need
to
know,
do
any
censorship
and
will
be
that
it's
not
super
difficult
for
a
membrane
to
already
to
to
do
a
censorship,
because
membrane
is
already
at
least
the
ones
that
we
have
already
implemented.
Censorship
process
for
errors
and.
C
B
So
the
one
that
we
have
it,
it
produces
an
error
and
a
an
error
that
does
not
contain
information
about
the
inner
pieces
of
what
happened
inside
that
side
of
the
membrane,
at
least
the
one
that
we
use.
So
it's
already
censoring
and
it's
not
censoring
by
analyzing
their
stack
because
that's
more
difficult
as
Matthew
was
saying,
the
the
stack
is
very
different
from
browser
to
browser
yada
yada.
B
What
we
do
is
we
throw
a
new
error
and
then
we
go
through
the
message
of
that
error
to
cut
out
whatever
it
was
left
behind,
so
it
cuts
out
some
of
the
pieces
of
it.
So
you
only
get
to
know
certain
information
that
we
provide.
So
that's
the
kind
of
thing
that
we
do,
but
my
point
is
that
membranes
can
do
this
membrane.
C
So
I'd
like
to
prove
that
the
the
technique
that
you
talked
about
is
only
for
throwing
errors
not
for
creating
errors
and
looking
at
them.
So
if
I'm,
deep
in
a
you
know
if,
if
I've
received
control,
I'm
an
object
in
some
realm
and
I've
received
control,
but
the
the
at
the
point
that
I've
received
control
were
these,
you
know
I'm
already
deeply
nested
in
a
synchronous
cross
realm
stack,
then
I
create
an
error:
I,
don't
throw
it
I,
just
create
it
and
then
I
do
error.stack.
D
B
Right
but
then
the
the
the
the
flip
side
of
the
is
that
when
you
do
want
to
provide
the
developer
you're,
not
doing
a
membrane
you're,
just
spinning
out
of
a
shadow
wrong,
and
you
want
the
developers
to
have
that
experience
or
if
there
is
an
error
in
any
part
of
the
code
that
they
are
executing.
You
want
to
provide
the
full
stack.
So
it's
a
develop
productivity
hot
on
right.
Now
you
want
to
see
the
full
stack
you
want
to
see.
What's
going
on.
D
B
Talking
about
I'm,
not
talking
about
the
dev
tool,
I'm
talking
about
chromatic
and
getting
my
error,
I'm
serializing
that
I
run
send
it
over
to
my
to
my
collection,
Mechanics
for
errors
to
report
error
and
so
on.
So
I
news,
the
the
stack
of
where
the
error
occur,
because
it
was
censored
by
these
these
shadow
realm
so
most
likely
in
an
application.
If
you
have
any
kind
of
error
control
that
you
lock
and
you
want
to
go
back
to
that
and
plug
them
and
be
able
to
inspect.
B
What's
going
on
with
your
app,
you
will
be
putting
error
controls
at
the
main
ROM
in
the
window,
then
you're
sending
them
over
to
a
server.
If
I
have
a
shadow
ROM,
then
I'm
and
the
shutter
I'm
doing
censorship
that
are
has
no
information.
That
I
can
really
be
useful
for
me.
If
I
do
the
death
tool
yeah,
the
death
tool
can
do
all
that
all
the
things
all
these
extra
steps
to
provide
a
lot
more
information
about
what's
going
on
really.
C
B
C
About
wait,
wait,
sorry,
the
the
so
so,
first
of
all,
forgetting
Shadow
realms
for
a
moment
in
general
membranes
are
something
that's
placed
between
things
where
the
the
the
party,
placing
the
membrane
between
things,
doesn't
necessarily
have.
You
know
privilege
over
the
things
that
they're
placing
the
membrane
between.
C
So
you
know,
in
order
for
me
to
place
a
membrane
between
Alice
and
Bob
doesn't
mean
that
I
already
have
the
ability
to
replace
Alice's
or
Bob's
error,
Constructor
right,
Alice,
Alice
and
Bob,
and
and
and
myself
might
all
be
mutually
suspicious,
but
Alice
and
Bob
don't
yet
have
any
contact
to
each
other.
I
have
access
to
both
Alice
and
Bob
I
decide
to
put
them
in
contact
with
each
other's
remembering
I.
C
Didn't
that
the
fact
that
I
can
put
them
in
contract
through
a
membrane
does
not
mean
that
I
could
replace
Aleister
Bob's
error
Constructor.
So
we're
talking
about
something
more
powerful
than
a
membrane,
I.
Think
you're,
I
think
you're.
You
karidi
are
thinking
in
terms
of
the
mere
the
near
membrane,
which
is
a
lot
more
mechanism
than
a
membrane.
D
I
I,
so
Alex
raised
a
few
questions.
I'll
quickly
address
them.
So
could
this
be
a
point
where
Shadow,
Realms
and
compartments
are
different
according
to
stack
Trace
I?
Think
so,
because
errors
are
shared
within
a
compartment,
so
we
are
not
I.
Don't
think
anybody
has
looked
into
censoring
but
stack
traces
across
compartment
boundaries
so.
C
We
need
we
need
to
be
very
careful
about
what
you
can
and
cannot
what
can
and
cannot
differ
across
compartment
boundaries
for
an
error
instance,
when
you
say
error,
dot
stack,
there's
nothing
compartment,
oriented
about
that,
the
the
there's
no
there's
there
that
cannot
be
dependent
in
any
way
on
what
compartment
it
it's
happening
in,
because
it's
not
happening
in
a
compartment.
It's
just
happening
right,
it's
it's
so
the
so.
The
the
you
know
the
the
SES.
C
C
And
to
get
this
thing
right
that
yeah
right,
so
they
so
for
so
in
a
in
a
post,
lockdown
World
error
instance,
dot
stack
gives
back
no
information
and
all
of
the
information
to
get
error.
Stacks
has
to
be
either
hung
off
the
global
or
hung
off
a
separate
per
compartment
error,
Constructor
all
right,
so
an
error
Constructor
that
could
be
separate
per
compartment
and.
C
D
I
think
this
is
a
decent
segue
back
to
Shadow
realm
and
what
I
wanted
to
mention
I
think
we
keep
mixing
two
things
here.
We
we
keep
mixing
creating
a
narrow
instance
and
looking
at
the
stacks
and
having
a
a
error
bubble
back
to
the
to
cross
the
callable
boundary
and
being
able
to
observe
the
stack
information
across
and
those
are
actually
two
different
things.
D
What
happened
there
if
a
mirror
is
thrown
inside
the
shadow
realm
and
Bubbles
back
through
a
callable
boundary?
What
you're
saying
is
that
the
the
incubator
realm
should
have
enough
should
be
able
to
observe
enough
stack
information
on
whatever
is
thrown
to
be
able
to
understand
and
Report,
and
that
might
be
acceptable.
D
D
B
I,
so
I
don't
think
we
have
that
distinction
today
in
the
spec
I.
Remember
that
distinction
of
incubator,
ROM
or
the
shadow
ROM
or
in
nested
Shadow
ROM
and
the
jubera
ram,
although
I
don't
think
we
have
any
distinction
there,
we
could
make
that
distinction.
I
I
like
the
idea,
because
then
it's
what
she
was
saying
like
we,
you
I'm,
creating
the
shadow
around
maintenance
so
like
why?
Why
I
should
not
be
able
to
see
what's
going
on
there?
B
Of
course
there
are.
There
are
cases
in
which
in
a
single
child,
around
maintenance
and
they
equator
for
that,
it's
still
complicated.
If
you
have
multiple
calls
in
between
then
say,
if
you're
calling
him
to
a
shadow
ROM
through
a
callable
and
then
the
shadow
realm
is,
has
received
a
callback
and
calls
that
callback
that
goes
out
and
then
they
call
back
try
to
do
something
and
throw
the
narrow,
then
what
what
is
the
information?
B
D
Doesn't
have
to
that's
the
thing
the
the
hosts
the
can,
since
Stacks
are
a
host
control
right
now.
The
error
that
crosses
the
thing
that
crosses
over
the
callable
battery
can
include
private
information
that
can
be
fetched
again
if
it
crosses
another
recallable
battery,
so
you
throw
a
mirror
inside
a
callback
that
goes
back
into
a
a
a
a
another
Realm.
A
D
B
And
if
that
error
has
information
about
the
arena
error,
then
we
might
be
able
to
get
that
information
out
of
the
Arena,
rather
than
the
already
wrapped
error
or
some
sort,
and
so
we
could
do
some
of
that
to
allow
one
side
to
access
the
full
stack.
When
you
decide
my
my
access
to
a
sensor
stack
now,
there
are
there's
a
couple
of
issues
with
that
approach
that
I
I
like
that
approach.
B
First
of
all,
I
like
that
approach,
it
kind
of
allow
the
owner
of
the
Shadow
to
get
access
to
everything,
and
then
the
shadow
is
sensored
in
a
way
that
can
only
access
certain
information.
So
I
like
that
I
think
people
will
be
okay
with
that,
especially
because
from
within
the
shadow,
you
can
really
do
much.
You
might
be
able
to
to
lock
that
error
into
the
server,
but
normally
you
do
that
outside,
as
you
mentioned.
B
B
Yeah
so
I
think
that
that
would
be
fine,
but
it
will
be.
It
will
be
so.
Okay,
so
I'll
look
into
what
what
what
the
implications
are
there?
Let's
assume
that
we
have
that
already
to
know
who
they
call.
The
incubator
is
who
the
child
Ram
is,
and
then,
therefore
we
can
make
that
decision.
So
that's
one
issue,
I
think
that
I,
don't
think
that's
impossible.
I
think
that's
perfectly
impossible
how
complex
it
is.
I,
don't
know.
B
The
second
issue
is
a
little
bit
more
tricky
and
I'll
put
an
example
of
it,
and
then
we
can
talk
about
the
actual
issue.
So
if
I
have
a,
if
I
have
a
and
I
think
you
touch
on
it,
if
I
have
a
incubator
round
like
crazy,
Shadow,
ROM
and
then
the
shadow
round
creates
another
Shadow
wrong
and
the
nests
are
around
throws
an
error
that
is
captured
by
the
the
incubator
shot
around.
B
You
haven't
crossed
the
boundary
to
the
outside
to
the
actual
incubator.
So
what
kind
of
information
would
that
error
contain?
That
will
be
censoring
information
that
might
be
about
the
incubator
run,
which
is
the
one
that
initiates
the
call
to
a
function
to
level
down
or
something
like
that.
So
you're
not
really
Crossing
anymore,
that
boundary.
If
you
haven't
get
across
that
boundary
and
then
what
what
kind
of
censorship
you
apply
there
and
based
on
what?
Because
you
don't
know
that
there
is
another
incubator
outside
that
is
trying
to
censor
what
what
you're?
D
B
I
I
think
it
should
I
think
it
should.
But
that's
not
my
question.
My
question
is
the
incubator
receive
a
function
that
crossed
two
boundaries,
so
it
crosses
twice
which,
by
the
way,
it's
just
going
to
be
obviously
a
different
function,
because
it's
a
different
wrong,
but
it's
bound
to
the
same
ROM,
which
is
the
the
Aina
one
and
now
it
calls
that
thing
and
nothing
throws
an
error.
B
But
there
is
a,
let
me
see
so
if
the
incubator,
one
is
the
one
invoking
that
function
directly,
the
middle
one
doesn't
doesn't
capture
that
or
it
goes
straight
into
the
car
which
you
can
censor.
But
it's
not
you.
It's
not
your
incubator
anymore,
because
we
don't
track
that.
Maybe
that's
what
you're
saying
that
you
need
to
build
that
graph.
B
B
D
I
was
thinking
we
can
probably
hand
hold
the
the
implementers
there
and
and
constructs
a
graph
with
slots.
So
I
have
a
new
type
of
over
there
that
is
thrown
across
a
callable
binary.
That
includes
a
slots
with
the
reference
to
the
original
error
on
the
other
side.
So
they
have
a
place
to
look
for
it
and
and
reference
it
in
their
own
spec.
But
we
don't
do
anything
with
it
and
then
we
explain
that
you
can
use
this
to
access
that
information
of
the
nested
errors.
C
B
C
C
B
C
D
C
D
C
Yeah,
so
what
we've,
what
we've
proposed?
So
this
is
where
the
these
the
stack
error,
stack
proposal
that
predates
all
the
shadow
realm
stuff
where
the
error
stack
proposal
actually
is
relevant
here,
which
is,
we
are
proposing
that
stack
B
standardized
as
an
accessor
on
error.prototype
and
as
a
configurable
accessor,
so
that
it
can
be
removed
or
replaced,
and
we've
proposed
that
believing
that
we
can
get
Safari
willing
to
change
to
that.
C
B
So
I
think
after
looking
at
this
and
then
I
think
Dave
Matthews
proposal
is
still
solid
proposal.
Well,
I'm
talking
about
the
one
that
censor
sensor,
the
the
sensor,
the
access
to
stack
from
within
a
ROM
but
from
the
incubator,
you
can
always
see
the
entire
stack
by
looking
at
this
code.
This
code
will
have
to
work
at
the
engine
level,
not
at
the
callable
boundary
level.
B
D
That
are
happening.
There's
two
parts.
There's
two
parts:
there's
the
stack
about
an
error
that
you
construct
within
your
own
within
your
own
realm
and
whether
that
contains
information
of
stacks
of
Stack
frames
outside
of
your
Realm,
and
that
should
be
that
should
be
censored.
And
then
there
is
the
cases
of
how
what
kind
of
stitching
is
the
hosts
allowed
to
do
on
your
behalf
when
a
mirror
crosses
the
battery,
and
that's
where
I'm
saying
like
we
technically
don't
have
to
construct
a
graph.
D
B
I
think
I,
understand,
I,
think
we're
going
back
to
the
the
conversation
about
keeping
the
antenna
slot
to
the
arena
error.
That
is
a
cross
realm
error,
you
know-
or
maybe
it's
not
maybe
implementers
will
not
really
keep
an
error,
but
something
that
can
be
used
to
build
a
stack
doesn't
have
to
be
there.
So
we
don't
have
to
be.
We
don't
have
don't.
B
B
You
can
see
it,
but
your
sensor,
you
see
the
entire
stack
all
the
way
down,
but
you
don't
see
the
the
stack
outside
of
the
realm
that
you
are
on
and
then
you
throw
it
again
and
then
it
crosses
the
boundary
again
and
on
the
outside,
you
should
be
able
to
see
the
entire
thing.
Three
two
levels
out
and
so
on.
So
so
I
feel
that
the
part
on
the
on
the
callable
boundary
is
fine.
We
can.
We
can
do
that.
B
B
It's
not
about
Shadow
realm
specifically,
even
though
it's
or
it
only
applies
to
Shadow
ROM,
but
we
should
put
something
somewhere,
because
we
don't
have
a
stack,
we'll
have
to
figure
out
where
to
put
it,
but
something
that
says
well,
if
the
engine
construct
an
error,
the
stack
of
data
must
be
the
the
the
error.
Data
should
be
should
have
the
entire
information,
but
the
error
stack
should
be
built
or
stitched
together
in
such
a
way
that
you
don't
leak
information
about
the
outside
of
that
realm
and
and
then
that
seems
sufficient.
B
So
we,
this
is
just
two
two
different
things
that
we
have
to
do
there,
but
I
feel
that
with
that
without
having
specified
anything
about
message
or
anything
about
name
or
the
error,
or
anything
specifically
about
stock,
just
providing
notations
about
what
the
notation
but
the
information
about
what
we
expect
to
be
censored.
And
why
know?
Why
like
what
to
be
censored?
And
then
that
that
seems
sufficient
to
me.
E
B
B
B
This
one
seems
to
be
coherent
with
some
of
the
intuition
that
some
people
has
expressed
like
shoes
and
for
an
outside
I
should
be
able
to
see
what
happened
inside
Jordan's
saying
well,
if
this
is
for
membranes
and
the
membrane
should
be
doing
that,
while
there's
now
a
justification,
why
the
membrane
cannot
do
that?
There's
an
example:
why
I
cannot
do
that
and
so
on,
and
then
we
come
up
with
this
proposal
that
is
somehow
simple
to
implement
and
we
have
all
the
pieces
in
place.
D
B
E
C
D
Jordan
tried
something
with
errors
and
cause
and
whether
engines,
let
me
try
to
remember
I,
think
engines
should
be
allowed
to
have
a
own
a
property
or
not
or
or
something
on
the
Prototype.
Anyway.
I,
don't
remember,
I
exactly
the
details,
but
from
I
remember.
The
the
committee's
consensus
was
that
implementers
are
allowed
to
extend
tc39
defined
objects
and
and.
B
C
D
C
A
An
important
difference
yeah
so
we're
at
10
minutes
to
the
hour
I'm
trying
to
be
sensitive
to
the
people
needing
breaks
between
meetings
on
days
where
people
have
meetings
back
to
back.
If
this
is
a
good
place
to
stop,
let's,
let's
go
off
the
Record.
Does
anybody
wish
to
continue
all
right?
Thank
you
and
success
meeting.