►
From YouTube: SES-mtg: report on March tc39 meeting
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
A
A
They
are
not
interested
in
Jessi
and
the
reason
is
that
SES
is
close
enough
to
JavaScript
that
many
JavaScript
programs,
many
existing
JavaScript
programs
run
even
Jessie,
even
though
you
have
the
compatibility
one
way,
everything
written
to
Jessie
will
run
as
JavaScript
going
the
other
way.
It's
such
a
bizarrely
different,
subset
of
JavaScript
that
essentially
zero
existing
JavaScript
programs
run
in
Jessie,
which
which
I
do
expect
to
be
true
so,
and
you
know,
and
in
explaining
to
tc39.
A
This
fits
very
well
with
what
I
was
stating
happened
at
TC
53,
which
is
it's
really
SES
that
I
expect
to
be
trying
to
advance
in
tc39.
The
other
thing
that
I
did
state
clearly
I.
Think
not
the
first
time.
Is
that
the?
What
had
been
three
layers
for
us,
which
is
the
realms
API?
On
top
of
that
the
frozen
realms
API?
And
on
top
of
that,
the
SES
that,
as
we've
continued
work,
there
was
not
a
difference.
A
A
A
One
of
the
things
that
came
up
painfully
is
the
degree
to
which
normal
JavaScript
should
remain
constrained
to
be
as
compatible
as
possible
with
SES,
and
there
was
the
issue
of
as
JavaScript
begins
to
standardize
some
api's
that
are
conceptually
resources
rather
than
pure.
How
should
those
be
provided
so
that
they're
well
segmented,
so
that
they're
well
quarantined
from
the
rest
of
JavaScript.
C
A
C
Sorry
one
clear
clarification
here:
I'm,
just
not
sure
what
you
mean
by
virtualization
are
we
oh
yeah,
hi,
sorry
I
kind
of
jumped
in
a
bit
late
in
the
game.
So
so
are
you
talking
about
virtualization
in
terms
of
you?
Don't
remove
it
from
global,
but
you
don't
include
it
into
the
realm
and
then
you
have
somebody
proxying
stuff
from
it
that
you
will
trust
so.
A
A
A
Log
is
not
standardized
by
Ekman
script.
Perhaps
it
should
be,
but
it's
not
right
now,
if
it
were
standardized
and
we'd
need
to
be
standardized
as
a
power,
because
it
is
exactly
I/o
to
the
to
the
external
world,
and
so
so
in
the
primal
realm
there
would
be
the
which
is
not
an
SES
realm.
There
would
be
the
original
console
dot
log
and
then
there
would
be
bootstrap
code
running
in
the
primal
realm
that
uses
the
SES
API
to
create
a
new
SES
root
realm
and
then
that
SES
root
realm.
A
A
So
the
code,
the
bootstrap
code
in
the
primal
realm,
would
wrap
console
dot
log
with
wrappers
that
were
objects
within
the
SAS
realm
and
would
install
that
console
dot
log
and
that
might
be
also
attenuating
aspects
of
console
dot
log,
depending
on
what
powers
you
want
to
provide,
but
that
would
take
that
wrapper
and
install
it
on
the
the
global
of
what
I'll
call
the
start,
complain
and
I'm.
Assuming
that
we're
in
the
you
know,
the
legacy
safe
module
support
world
where
we
are
using
multiple
compartments
with
multiple
Global's.
A
So
so
there
would
be
of
the
new
compartments
so
sub
sorry,
so
the
bootstrap
code
would
make
a
root
realm
and
there
would
make
a
first
compartment
within
the
root
realm,
which
is
the
Start
compartment
for
the
application.
That's
going
to
run.
It
would
install
this
tamed
console
object.
That's
that's
our
previous
terminologies.
A
A
I'm,
so
we
need
to
get
into
the
actual
module
namespace
to
complete
the
story
and
that's
the
thing
that
we're
all
working
on
and
it's
partially
formed
so
I'm
going
to
skip
over
that
for
the
moment.
But
the
module
namespace
I.
A
The
code
that
runs
in
that
start
compartment
would
start
up
other
compartments
and
might
grant
to
another
compartment
a
further
virtualization
of
the
console
object
or
might
simply
not
provide
the
console
object.
It
would
be
up
to
this
to
the
code
in
the
start
compartment
what
to
do
with
the
attenuation
it
has,
but
it
could
not
grant
anything
more
than
the
attenuated
form
that
it
has.
C
Yeah,
no
thanks
that
really
helps
and
I
think.
My
question
was
confusing:
not
that
I
wasn't
confused
when
I
asked
them
myself,
but
but
it
was
really
about
the
process
of
Timmy
waiting,
a
global
that
already
exists
before
you
make
a
frozen
round,
because
I
think
it
will
factor
in
the
SAS
frame
for
sure.
So
so
I
just
wanted
to
know
how
to
deal
with
things
like
that
and
I
think
the
answer
definitely
covered.
Thank
you.
Yeah.
A
And
it
fits
by
the
way
very
well.
This
thing
of
virtualized
system
powers
fits
very
well
with
my
way,
my
new
way
of
explaining
the
realm
API,
which
has
gone
over
very
well
in
tc39,
especially
with
a
lot
of
the
side
conversations,
but
also
in
the
main
conversation,
which
is
to
explain
a
realm
as
a
mechanism
that
allows
JavaScript
code
to
act
as
an
arbitrary
host
to
other
JavaScript
code.
A
A
One
possibility
going
forward
is
at
the
realm
level,
but
not
of
concern
to
the
SES
level.
The
realm
level
we
probably
want
to
do
is
to
provide
a
time
hook
or
a
now
hook,
so
that
the
creator
of
a
realm
can
provide
a
source
of
time
and
then
any
built-in
thing
in
the
created
realm
that
that
is
trying
to
perceive
the
current
time
using
the
built-in
gets.
The
one
created
by
the
creator
of
the
realm
gets
gets
the
one
provided
by
the
creator
of
the
realm
very
case.
A
A
So
with
stack
traces.
There
is
a
existing
API,
which
is
present
in
the
primordial
objects,
which
is
for
from
an
error
object.
You
can
say,
error,
object,
dot,
stack
and
what
we've
specified
in
our
proposal
is
that
that
property
is
actually
defined
on
error,
dot
prototypes
and
it's
inherited
by
the
error
instances,
which
was
what
Mozilla
actually
does.
Let
me
know
it's
web
compatible,
but
we've
also
moved
it
into
an
aquarium
that
that
part
of
the
stack
API
be
in
mxb,
so
that
a
conforming
implementation
can
remove
it
and
the
SAS
implementation
does
remove
it.
A
But
in
its
place
there
are
separate
operations,
powerful
operations,
which
is
get
stack
and
get
stack
string
that
make
the
same
information
available
by
other
means
and
those
are
defined
right
now.
The
proposal
has
them
defined
on
the
system
object,
which
is
a
namespace
object
like
math,
where
we've
proposed
that
all
special
powers
come
from
the
system
object,
and
the
reason
for
that
is
that
secure
code
like
an
SEM
can
can
know
that.
A
That's
where
special
dangerous
things
are
and
therefore
can
easily
omit
it,
or
only
allow
the
things
that
it
knows
how
to
attenuate
and
censor
everything
else
or
whatever,
but
basically
preserve
the
system
versus
user
mode
distinction
that
right
now
we
have
as
a
boundary
between
Ekman
and
house
to
preserve
that
distinction.
Even
when
tc39
define
some
system
objects.
A
A
A
The
other
Jordan
Harbin
Maiko
champion
on
the
eros
tax
proposal
also
has
a
very
nice
proposed
alternative
to
the
system.object,
which
is
much
more
whitelisting
oriented
than
blacklisting
oriented,
which
is
also
very
nice
from
a
security
point
of
view,
which
is
actually
before
I,
say
this
I
should
say
what
the
constraint
on
the
design
is.
A
We
want
old
securing
code
like
an
SDM
old
securing
code
that
was
safe
for
the
version
of
ECMO
script
that
it
had
deployed
it
for
to
remain
safe
under
new
versions
of
Ekman
script
and
therefore
be
able
to
censor
powerful
things
that
it
didn't
know
about,
while
at
the
same
time
having
it
not
censor
new,
powerless,
pure
if
frozen
things
that
it
didn't
know
about.
We
would
like
the
old
code
to
be
compatible
with
the
platform
rolling
out
new,
safe
things
and
new
unsafe
things
without
the
old
code
censoring
the
new,
safe
things.
A
A
A
And
it
simply
omits
new
powerful
things
and
the
thing
about
asking
the
platform
for
it
is
then
it's
the
the
old
safe
code
is
is
up
to
date
with
whatever
platform
it's
running
on.
You
don't
have
the
coordination
problem
of
the
white
list
versus
the
version
of
the
platform.
It
simply
always
describes
the
platform
it
itself
is
on,
and
if
there
is
a
mistake,
shimming
code
can
still.
A
You
know
prior
vetted
shims
could
still
repair
the
white
list
to
repair
the
mistake
in
cases
where
there
is
a
mistake,
but
it
would
default
to
working
in
the
safety
preserving
way.
Another
possibility
that
I
discussed
with
Daniel
Ehrenberg
for
yet
another
powerful
thing
to
introduce,
which
is
how
do
we
want
to
introduce
the
ability
to
perceive
the
current
time
in
a
principled
way
if
we've
censored
it
from
the
date
object
is
built
in
modules.
A
B
And
makes
sense
so
the
the
idea
is
by
introducing
a
new
API
that
only
SES
would
be
interested
in
using
that's
not
going
to
be
a
burden
on
anybody
else.
A
Yeah
so
like
there's
like
Jordans
thing,
where
you
have
the
whitelist,
adding
a
whitelist
would
not
be
a
burden,
because
everyone
else
would
just
see
the
global
variables
they
wanted
to
see
right
and
likewise,
if
the
built-in
module
distinction
did
not
impede
the
usability
of
the
built-in
modules,
then
that
also
would
not
create
pushback.
There
is
a
staging
issue
here,
which
is
built-in
modules
are
not
even
yet
proposed.
Nobody
has
a
proposal
yet
so
we
don't
know
what
they're
going
to
look
like.
A
A
A
The
proposal
would
omit
the
part
of
the
moment,
API
that
requires
moment
to
know
the
current
time
that
it
that
that's
already
part
of
the
moment
proposal.
So
that
already
has
that's
already
acceptable
to
the
committee.
Dan
has
no
problem
with
that,
but
given
that,
where
does
the
capability
to
obtain
the
current
time
such
that
you
can
feed
it
into
moment
and
get
moment
functionality,
that's
applied
to
the
current
time
and
that's
where
a
current
time
built-in
module?
A
That
is
somehow
considered
part
of
a
bundle
with
moment,
but
has
factored
out
the
dangerous
part
of
moment
into
a
separate
thing
and
I
like
that.
That
means
that
in
general,
when
somebody
wants
to
package
stuff
as
modules
where
there's
some
power
there,
they
can
package
it
divided
into
all
the
computational
functionality
like
rendering
and
parsing
and
and
date
interval
and
data,
arithmetic,
put
all
the
computational
services,
the
transformational
services
in
a
pure
module
and
then
the
special
magic,
powerful
things
that
have
to
be
built
on
system.
A
And
moment
is
on
a
timeframe
where
it
might
be
not
irritating
to
all
of
the
stakeholders
for
moments
to
come
in
on
top
of
built-in
modules.
In
fact,
that's
sort
of
what
many
people
are
assuming
because
moment
has
is
a
very,
very
large
API
with
many
objects
and
a
lot
of
API
surface.
It
would
be
very
painful
to
just
include
all
of
those
objects
in
the
built-in
primordial.
A
You
you,
so
you
know,
as
this
group
proceeds,
to
define
safe
modules
for
SES.
We
can
also
have,
as
a
subtask
of
that,
to
English
in
our
shim,
actually
do
something
to
emulate
what
we
would
like
to
propose
for
built
in
modules,
including
the
separation,
and
then
that
would
be
a
basis
for
weighing
in
on
how
Dalton
module
should
get
standardized
in
ACMA
script.
A
You
you,
oh
and
I,
have
a
piece
of
very
good
news.
I
think
we
had
discussed
here
previously
the
import
maps
coming
from
the
browser
at
the
time.
I
really
did
not
understand
them.
Yet
that
was
really
my,
but
in
any
case,
Dominic
gave
a
talk
not
at
tc39,
but
at
another
JavaScript
event.
Immediately
following
tc39
that
I
attended,
he
gave
a
talk
on
import
maps
and
separately.
A
A
But
it
was
only
one
talk
and
one
offline
conversation,
so
I
might
have
missed
something,
and
that's
why
I'm
being
cared
very
careful
to
say
the
applicable
subset
of
import,
Maps
I,
don't
actually
know
of
anything
dangerous.
So
the
ideal
outcome
is
that
we
would
just
use
import
maps
and
safe
modules
and
then
propose
it
to
node
in
the
short
term,
into
tc39
as
a
language
wide
mechanism
for
the
longer
term.
B
A
B
A
The
import
Maps
coming
from
the
browser
think
of
the
result
of
name
resolution
always
being
a
URL,
but
neither
Daniel
nor
I
saw
anything
in
the
mechanism
that
makes
it
specific
to
URLs.
But
that
would
be
something
to
watch
out
for
is
that
URLs
sort
of
imply
this
global
namespace
of
the
internet
that
you're
giving
access
to
whereas
screens,
whose
meaning
is
created
by
the
loader,
are
very
different.
Obviously
those
strings
could
have
the
form
of
the
URL,
but
but
the
URL
form
suggests
the
wrong
thing.
B
A
We
would
might
get
more
attendance
back
and
the
reason
why
this
came
up
is
actually
that
it's
also
a
large
time
commitment
for
me
every
week
and
I've
got
even
though
it's
central
to
what
I'm
doing
I've
got
enough
other
things
to
do
to
actually
act
on
the
ideas
that
we
talked
about
here.
That
I'd
like
to
drop
it
to
one
of
these
sessions
a
week
I've
got
both.
A
Good
and
I
see
Daria
dropped
out,
so
that
is
a
unanimous
either.
One
works
for
me,
I'm,
going
to
because
the
constraints
I've
got.
One
was
a
hard
constraint
and
the
other
one
was
a
strong
preference.
Well
I
hereby
pick
Thursday
until
we
get
pushed
back
that
it
was.
The
wrong
decision
sounds
good,
but
that
will
include
two
days
from
now,
so
that'll
be
the
first
Thursday
only.
A
A
The
thing
that's
controversial
is
to
what
degree
the
the
anticipated
SES
should
constrain.
What
the
language
looks
like
in
non
SES
and
if
there's
already
some
incompatibility
there,
which
is
we
freeze
the
primordial.
That
means
not
a
hundred
percent
of
Ekman
script
code
runs,
and
that
means
that
we
could
admit
other
such
discrepancies
over
time.
Sorry,
Michael,
I'm,
just
finishing
this
up.
A
We
could
admit
other
such
discrepancies
over
time,
but
I
expressed
in
pushing
back
on
that
I
expressed
that
the
problem
is
the
death
of
a
thousand
cuts,
is
everyone
seems
small
and
in
aggregate
you've
created
a
new
language
and
no
JavaScript
code
ports
anymore.
The
only
reason
that
we're
in
the
city
in
the
fortunate
situation,
we're
in
is
we've
been
so
careful
not
to
admit
things
incompatible
with
SES
into
the
language
and
to
admit
things
in
a
way
that
is
SES
compatible.
B
A
B
A
B
So
what
I'm
curious
about
is,
how
can
we
get
there
from
here
and
in
turn,
support
environments
that
in
general
might
not
have
import
either
and
I
I
guess
there
are
two
main
approaches
that
I
seen,
one
of
which
is
to
just
say:
jesse
code
is
implicitly
a
bundle
because
it
does
not
use
dynamic
important.
So
it
doesn't
really
need
first-class
in
word,
and
another
approach
would
be
to
do
something
where
we
do
asynchronous
import
and
then
make
the
resulting
important
modules
available
to
a
namespace
to
evaluate
with.
A
A
I
would
like
to
I
would
like
to
have
a
plan
to
get
to
imports
being
directly
supported
by
SES
in
a
way
that's
adequate
for
Jesse's
purposes
sooner
rather
than
later.
Okay,
so
the
interest
the
nice
simplification
there
is
that
Jesse
only
supports
pure
modules
and
the
overall
safe
module.
Work
for
SES
has
pure
modules
as
a
component.
A
So
what
I
would
like
to
do
is
to
preserve
the
the
SES.
This
is
definitely
a
issue
of
layering
the
implementation
of
the
Shem.
It
is
not
an
issue
with
regard
to
what
to
specify
right,
but
for
the
Shem
I
would
like
the
existing,
tiny
SES
kernel
to
only
have
evaluators,
because
we
can
do
that.
We
can
do
safe
evaluation
without
parsing
and
then
to
do
a
source
to
source
transformation
of
modules
into
evaluable
scripts.
A
Already
are
evaluable
scripts
rather
than
separate
syntax.
That
needs
to
be
parsed,
so
we
could
support
we
could
have.
We
could
basically
get
our
safe
module
mechanism
working
more
quickly
in
a
way
that
was
usable
more
quickly
if
we
did
pure
modules
for
commonjs
first
and
then
at
a
at
a
higher
level,
did
a
translation.
A
A
What
that
suggests
is
that
we
could
start
with
a
very
simple
translation
for
which
we
know
in
what
way
it.
It
has
a
semantics
changing
hazard,
which
is
basically
just
turn
import
into,
require
and
turn
the
set
of
exports
into
the
assigning
of
an
exports
record,
miss
and
clearly
that
does
not
preserve
for
the
larger
SES
language.
That
does
not
preserve
the
semantics
of
Ekman
script
modules,
but
it
would
allow
I
think
that
would
enable
Jessie
to
run
immediately
on
top
of,
as
as
a
subset
of
SES.
Once
we
have
those
two
pieces
in
place.
B
That's
me
is
exactly
the
kind
of
transformation
we
need
to
do,
and
it's
not
just
us
yes,
that
this
is
an
issue
for
it's
any
environment
that
doesn't
support
imports.
We
have
and
in
some
ways
we
have
to
implement
the
same
rewrite
or
code
transformation
to
get
it
into
a
form
that
the
environment
cannot
handle.
So
it's
not
a
it's,
not
an
onerous
thing
to
do
that.
For
us.
Yes,
mm-hmm.
A
A
Another
relevant
thing
here,
which
I
think
I
think
this
plan
fits
with
perfectly
well,
is
that
for
embedded,
the
excess
engine
is
very
very
interesting.
I
mean
the
TC.
53
is
very,
very
interested
in
supporting
SES
and
the
model
who
creates
the
excess
engine
is
very
interested
in
creating
a
configuration
of
the
excess
engine
that
is
directly
an
SES
engine.
A
I
think
we,
you
know,
we've
talked
about
that
extensively
before
in
these
meetings.
The
interesting
thing
there
is
the
typical
and
desired
moddable
configuration
is
that
the
Aetna
script
running
at
runtime
running
on
the
device
does
not
have
any
runtime
evaluators
their
module.
They
only
support
Atma
script
modules.
They
do
not
support
common
J's
modules
and
for
the
configuration
where
there's
no
run
time,
evaluation.
A
Basically,
all
of
the
module,
initialization
and
linkage
all
happens
at
Build
time
and
therefore
their
their
module.
Initial
state
is
pure
by
configuration
and,
and
that
means
that
what
they're
we
would
need
to
take
a
look
at
how
they're
using
modules
and
make
sure
that
the
plan
of
moving
that
to
SAS
will
fit
with
the
idea
that
those
modules
were
safe,
pure
SAS
modules.
B
B
A
B
B
A
I'm
talking
to
Daniel
Ehrenberg
the
there's
two
problems
with
service
workers
that
we
talked
about
and
I
should
say
that
I'm
sufficiently
unfamiliar
with
them
that
I
don't
have
I,
have
no
confidence
that
they're
not
problems
beyond
that.
You
that
we
talked
about,
but
the
two
that
we
talked
about
are
that
service
workers
do
not.
A
If,
if
you
don't
already
have
the
service
word
worker
running
and
you
load
a
frame
that
is
supposed
to
go
through
a
service
worker,
that
code
in
the
frame
can
start
running
prior
to
the
service
worker,
coming
up
and
being
interposed
and
there's
an
existing
proposal
for
I
think
it's
called
intercept,
onload
or
something
like
that
where
it
would
be
the
case
that
code
within
the
frame
was
delayed
until
the
service
worker
was
in
place.
That
would
be
very
good
for
us.
A
The
other
thing
that
we
talked
about
is
a
service
worker
is
scoped
to
an
origin.
So
all
the
requests
from
the
page
to
that
origin
would
go
through
the
Service
Worker,
but
all
of
the
requests
from
the
page
to
other
origins
would
not
and
the
reason
that's
the
case
for
service
workers.
Is
they
think
of
the
service
worker
as
being
a
local
proxy
for
a
remote
host,
where
it's
a
remote
host
at
an
origin,
rather
than
thinking
of
it
as
a
wrapper
around
the
code
in
the
frame?
Yes,.
B
A
A
All
right,
good,
good
I
forgot
about
that
yeah.
We
did
talk
about
that
before.
Okay
yeah
this
sounds
this
sounds
promising.
B
A
In
the
same
way
that
we're
strategizing
the
development
order,
for
how
do
you
get
egg
musket
modules?
And
you
know
you
know
the
the
strategizing
development
order-
degree
that
we
think
that
the
first
steps
only
have
work,
that's
necessary
anyway.
Yeah
make
the
thing
more
widely
usable.
It
would
seem
that,
even
though
you
might
only
be
interested
in
running
Jesse,
that.
A
B
The
simplest
way
of
putting
it
is
that
we
will
have
safe
browser
containment
for
SES
and
then
applying
a
chassis
parser
to
the
input
is
just
an
option
for
that,
so
I,
don't
I,
don't
see
them
as
being
a
separate
thing
necessarily
and
that's
what
Sol
and
I
were
talking
about
is
having
it
be
at
the
same
project.
Essentially,
you
can.
B
A
B
Basically,
as
long
as
we
can
sanitize
the
JavaScript
code,
the
Dom
can't
really
exert
any
Authority
besides
in
the
frame,
and
we
can
remove
the
parent,
the
parent
reference
from
the
frame
as
well,
so
they
can't
get
out
but
yeah
that
that's
that's
something
that
I
had
passed.
Some
familiarity
with
and
experience
with,
but
haven't
got
the
same
depth.
Understanding
it's
Allah
has
and
he's
basically
the
one
we're
working
on
that
part
and.
B
A
A
C
Can
do
that
so
can
I
can
I
pitch
in
here.
The
reason
why
I
thought
jesse
would
be
an
easier
target
than
SDS
is
because
of
the
language
had
like
the
subset
has
a
very,
very
restricted,
a
number
of
moving
parts
and
I
thought
of
the
eval
and
import
by
the
way,
the
dynamic
function
as
as
things
that
we
could
actually
eval.
We
can
replace
the
global
eval
and
then
we
can
sanitize
eval
code
that
is
being
about,
even
if
it's
not
jesse
code.
A
C
No
I
mean
I
mean
if
the
SES
frame
is
allowing
more
complexity,
because
it
allows
more
of
the
language
Jessie
frame.
I,
in
my
opinion,
was
a
good
start
because
it
has
a
subset,
a
smaller
subset
and
in
that
subset
my
concerns
were
eval
and
import.
So
I
do
like
I
know
that
SES
does
replace
the
global
eval
but
asked
here
concern
about
how
to
handle
it.
Val
before
I
before
I,
you
know
came
to
the
conclusion.
Oh.
A
Clarify
my
question:
yeah
se
yo
SES
handles
eval
through
JavaScript
evaluators
perfectly
well,
that's
not
what
I'm
worried
about
I'm
worried
about
access
to
the
Dom,
doing
things
like
creating
script
tags,
meaning
an
evaluation
by
their
means
and
I?
Think
I
think
the
CSP
is
say
enables
us
to
suppress
that
wanted
to
verify
that.
C
A
Good
and
as
far
as
you
know,
certain
various
tags,
a
script
or
image
or
whatever
having
a
a
circe
equals
and
then
a
URL
string.
We
can
through
CSP
for
all
of
those
we
think
suppress,
fetching
I'm,
sorry
front
templates.
We
consent
we
can
suppress
the
fetch.
Those
URL
strains
because
they're
in
a
template,
okay,
good.
C
So
yeah,
like
initially
the
idea
with
SES,
is
you
want
to
allow
people
to
actually
import
their
resources
right,
but
with
Jessie
frame?
The
idea
was
that
SRC
needs
only
to
point
to
Jessie
code
and
that
goes
through
the
service
worker,
so
so
I
think
a
more
simplified
CSP
policy
to
it
to
prevent
SRC
on
scripts
or
H
ref
on
iframe
would
be
a
good
start
until
we
have
that
in
place,
and
then
we
can
start
talking
about
what
assets
are
and
what
is
the
idea
of
an
adjust
for
a
min
side,
a
Jessie
frame.
C
C
So
with
SES
I'm
struggling
with
you
know
organizing
my
thoughts,
let's
put
it
this
way
on
the
broadness
of
sources
that
need
to
be
validated
before
executed.
So
I
can't
in
my
head
I'm
not
coming
up
with
a
concrete
plan
on
you
know
the
steps
I
need
to
take
to
make
the
prototype
so
that
I
would
actually
be
able
to
capture
any
reference
to
code
that
is
being
fetched
in
the
right
sequence.
C
So
I
I
think
it's
it's
not
that
a
plan
is
hard
to
come
by,
but
rather
that
the
problem
is
too
big
for
me
that
I'm
getting
distracted
away
from
you
know
implementing
the
the
foundation
of
the
whole
thing
so
with
Jessie
frame,
not
allowing
other
Akuma
script
code
and
in
fact
only
allowing
code
to
that
will
actually
be
validated
by
somebody
else's
distraction,
I'm
able
to
say:
okay,
I'm,
not
gonna,
try
to
solve
a
problem
before
I
actually
see
it.
So.
A
C
That
needs
to
kind
of
give
the
same
assurance
that
the
sources
that
are
coming
are
not.
You
know,
hijacked
in
the
remote
of
space,
so
so
I'm
not
sure
exactly
how
deep
we
need
to
dig
there
and
I
can't
really
create
a
clear
image
to
move
forward
with
that
complexity
in
the
way.
So,
to
my
knowledge,
the
the
benefit
of
the
jessica
validation
is
that
it
takes
that
problem
out
of
my
scope
completely
until
I
put
the
same
foundation
that
we
need
for
SDS
frame
in
a
smaller
problem
space.
So.
A
C
No,
that's
the
thing
I'm
trying
to
do
too
or
I'm
trying
to
put
in
in
some
term
or
some
definition
about
if
I'm
going
to
be
loading,
something
from
a
URL
but
I'm
going
to
be
remapping,
those
URLs
against
the
serviceworker
you're
about
on
the
web.
You
have
many
domains
and
many
sites
refer
to
assets
across
multiple
domains.
C
You
know
a
prefix
path
that
is
only
resolvable
by
the
serviceworker.
It
does
not
exist
in
reality
and
in
doing
this
kind
of
mapping,
you
will
be
getting
modules
that
will
have
to
at
some
point
refer
to
each
other.
So
you
want
to
know
that
you're
not
rewriting
something
and
breaking
its
linkage
to
something
else.
C
So,
if
I'm
getting
an
asset
that
is
importing
another
asset,
the
fact
that
the
serviceworker
serves
it,
a
local
pack
name
at
some
point-
there
might
be
conflict
whether
or
not
the
URL
should
be
remapped
in
the
source
or
should
be
remapped
outside
by
the
service
worker
which
which
does
not
exist
today.
So
this
is
the
feature
that
I
think
we
will
be
asking
for
from
the
web
community.
It's
the
ability
to
remap
URLs
before
loading
a
page,
but
since
we
don't
have
that
the
remapping
has
to
occur
in
serviceworker.
A
A
B
This
understanding
that
we
need
the
same
execution
environment
for
safety
is
the
bottom
line
here
and
that's
I
think
addresses
a
lot
of
sellers
concerns
about
different
origins
and
so
on.
But
to
get
to
have
something
that
works
within
within
jesse
frame,
for
example,
might
be
too
constrained
of
an
environment
to
use
for
us,
yes
frame.
So
solving
the
can.
B
Situation
that
I'd
have
is
a
public
web
site
that
serves
user
content
I
and
to
allow
scripts
and
other
and
other
color
to
import
only
from
that
site.
For
example.
Okay,
in
that
situation,
we
are
constraining
where
the
Jesse
Frank
can
go,
but
in
the
general
SES
frame
I
think
we
would
want
to
lift
that
restriction
more
for
Jessa
frame.
We
can
say
with
confidence.
We
know
we're
getting
all
of
it
from
this
one
site
because
of
the
content,
security
problem
policies
and
so
on.
Okay,.
A
B
B
A
Not
the
technique,
it's
none
of
the
technical
differences
between
SES
and
just
me.
Rather,
it's
the
developer
expectations
that
would
follow
from
something
supporting
SES
versus
something
supporting
Jesse.
Something
supporting
SES
developers
would
expect
to
pull
things
in
cross-origin
because
we're
supporting
we're
doing
so
much
work
to
support
some
legacy
code,
whereas
with
Jesse
you're,
sending
a
clear
signal
that
you
have
to
rethink
from
scratch,
which
you
know
which
web
mechanisms
are
supported,
is
that
am
I
getting
it
is
this?
What
is
this?
Is
this?
What
you're
saying
about?
Why
start
with
Jesse
Fred.
C
Definitely
yeah
so
so
solving
the
problems
that
are
much.
You
know
in
my
scope,
work
Barbee
not
to
get
distracted
in
potential
problems
that
are
much
much
bigger
than
what
you
would
expect
a
jesse
frame
to
be
able
to
do.
That's
it,
that's
a
good
rehashing
of
that,
so
it
has
the
SEO.
You
expect
the
entire
platform
with
jesse
frame.
You
know
that
the
entire
platform
may
never
be
supported
so
you're.
C
A
Developments
that
would
open
up
tremendously,
more
use
of
SES
and
I
would
be
pretty
sure
that
the
meta
mascius
of
SES
would
be
perfectly
fine.
With
this
restriction,
I
will
ask,
but,
as
an
example,
I
think
it
would
be
perfectly
fine
with
this
restriction.
A
lot
of
the
use
cases
I
have
in
mind
would
be
perfectly
fine
with
this
restriction.
A
So
let
me
just
success,
suggest
as
a
development
strategy
that
you
know
conceived
of
the
the
mechanisms
that
you
want
to
build
to
support
Jessie
frame,
go
ahead
and
build
them
with
the
intention
of
using
them
to
build
Jessie
frame,
but
for
all
of
the
browser
side
mechanism
they
could
building.
When
you
do
that,
just
lets
continually
ask
the
question
of.
A
B
A
Sc,
yet
no
SES
works
in
the
browser.
What
I
meant
is
yes,
I
see
I
see,
I
did
I
did
misspeak
I
didn't
mean
to
imply
that
SES
doesn't
work
in
the
browser.
What
I
meant
is
that
SES
currently
cannot
be
safely
exposed,
or
rather
untrusted
code
as
confined
by
SES.
If
you
give
it
an
attenuated
access
to
a
Dom,
node
you've
basically
lost
confinement.
A
A
Ses
was
the
JavaScript
component
of
that
that
we've
now
rebuilt
much
better,
but
kaha
also
had
a
component
called
D'amato.
Let
me
just
since
I'm
Tomica.
It
also
had
an
HTML
source
rewriter
and
a
CSS
source
to
source
rewriter,
but
those
were
not
nightmares.
The
nightmare
was
D'amato,
which
was
essentially
a
handcrafted
ad
hoc
membrane
sitting
between
the
untrusted
SAS
code
and
the
actual
browser
Dom
API,
and
the
reason
it
was
a
nightmare
is
that
the
Dom
API
is
one
of
the
worst
api's
that
human
beings
have
ever
created.
A
So
what
so?
The
current
mechanisms
that
we're
talking
about
would
allow
us
to
avoid
the
hellacious
work
of
trying
to
rebuild
dom
safety
by
intermediation.
If,
instead,
we
can
create
a
by
other
means,
a
confined
environment
in
the
browser
in
which
we
can
give
untrusted
code
direct
access
to
dom
nodes.
A
A
B
A
C
A
Broke
what
had
been
an
invariant
in
JavaScript,
which
is
that
special
powers
could
not
be
reached
by
syntax
in
script
code
and
the
reason
why
I
qualify?
That,
as
with
you,
know
qualified
that
as
within
script
code?
Is
that
the
import
statement
in
modules
really
has
all
the
same
power
as
the
import
expression
that
are
in
both
modules
and
scripts.
A
A
As
SES
proceeds
to
have
this
other
level
to
deal
with
modules
in
general,
it'll
have
all
the
mechanisms
needed
to
support
the
import
expression
as
well,
or
at
least
that's
what
we
should
that's
what
we
need
to
do.
In
any
case,
the
Committee
issue
is
that
import
expressions
are
at
stage
3.
They
are
already
implemented
across
at
least
some
browsers,
I,
don't
remember,
it
might
be
all
browsers,
but
it's
at
least
two
browsers.
A
A
It
was
just
an
issue
of
giving
us
this
community
another
two
months
to
try
to
shim
the
import
expression
in
the
realm
shim
to
the
point
that
we're
confident
that
the
spec
as
written
can
go
forward,
and
at
that
point
we
would
simply
allow
it
to
proceed
forward
to
stage
four.
If
we
find
a
problem,
you
know
in
an
edge
case
something
that
could
be
adjusted
without
breaking
legacy
code.
A
Right,
the
it's,
the
import
expression
looks
like
a
function
call
but
import
as
a
keyword,
so
the
import
expression
is
a
special
form.
There
is
no
lexical
binding
that
you
can
shadow
it's
it's,
so
it
directly
accesses
whatever
you
loading
service.
Whatever
module
loading
service
is
provided
in
that
environment,
it
accesses
it
dynamically
with
a
potentially
computed
string
and.
A
And
it
can
appear
both
in
scripts
and
in
modules,
and
it
returns
a
promise
for
the
module
object
rather
than
returning
the
module
object
itself.
The
string
that
is
fed
to
the
import
expression
is
is
dereferenced
according
to
the
script
or
module
it
appears
in
so
the
import
statement
in
modules,
a
given
specifier
strings
already
sensitive
to
which
module
the
import
comes
from.
So
you
can
do
things
like
relative
path
name,
the
import
expression
does
likewise,
except
since
it
can,
since,
since
it
can
also
appear
in
scripts,
the
spec
was
changed
to
say.
B
C
A
A
What
SES
does
right
now
at
the
SES
kernel
level,
where
we
only
have
evaluators?
Is
it
uses
a
cheesy,
regular
expression
to
scan
for
anything
that
looks
like
an
import
expression
include,
and
it
might
be
that
it
appears
inside
a
comment
or
inside
a
literal
string,
but
no
matter
where
it
appears.
If
it
matches
the
regular
expression,
then
we
just
reject
the
string,
safe
evaluation
and
so
far
that
hasn't
bitten
us,
but
clearly
that's
a
very
silly
thing
to
do.
A
A
You
know
there
are
these
perverse
examples
where
you
have
one
piece
of
JavaScript
code,
that's
valid
under
both
interpretations,
but
mean
something
completely
different
and
from
a
security
perspective,
that's
that's
worse
than
the
fact
that
the
existence
of
the
bizarre
syntax
in
the
first
place
is
where
you
can't.
You
have
to
validate
the
code
under
two
different
syntactic
interpretations
in
order
to
know
what
it
means.
So
I
am
planning
to
propose
that
this
crazy,
bizarre
syntax
be
moved
out
of
nxb
and
into
the
main
spec
and
made
normative.
A
C
So
I'm
glad
that
you
raised
that
point
because
I
actually
have
been
trying
to
parse
JavaScript,
for
you
know,
over
six
months
now
and
yeah
I
don't
give
up
right
so
I
get
the
tracted
trying
to
solve
problems
that
you
know
are
very
discouraging,
and
my
problem
is
I
did
not
see
any
of
the
existing
tooling
that
that
you
know
I
ran
their
source
code
because
they
tend
to
create
this
dist
files
that
have
all
the
caveats
of
parsing.
So
I
have
yet
to
see
any
one
of
those
you
know.
C
A
A
It's
also
I
believe
works
the
same
way
in
node
because
it
comes
from
v8.
The
tooling
issue
is
interesting:
I
hadn't
thought
about
that,
but
yeah
if
Babel
does
not
recognize
it,
then
that
that's
a
really
good
reason
to
make
a
normative
decision
on
this
thing,
because
for
Babel
to
differ
from
what
the
what
the
engines
do
directly
is
also
a
security
nightmare,
because
now
the
meaning
of
your
code
depends
on
whether
you've
run
it
through
a
Babel,
translation
or
not,
and
it
can
mean
different
things
in
different
circumstances.
C
A
Well,
yeah
the
acorn
behavior
by
the
way,
I
remember
that
somebody
responsibly
disclosed
a
caja
bug
to
Google.
That
was
a
big
deal
at
the
time
because
you
know
actually
good
cause
still
protecting
some.
You
know
significant
Google
properties
and
we're,
depending
on
a
corne
for
something
yeah
and
somebody
successfully
I
found
a
security
hole
in
kaha
and
fortunately
responsibly
disclosed
it.
So
we
could
fix
it
before
we
were
attacked
yeah.
He.
C
C
A
C
Know
like
they
always
start
off
in
the
first
few
lines:
I'm
not
gonna
scroll,
because
those
funds
are
very
huge
and
I'm,
using
like
literal
Dom,
rendering
but
usual
yeah,
there's
an
R,
but
usually
in
the
first
few
lines
whenever
they're
plagiarizing
they
they
they
meet.
I
guess
I'm
writing
the
wrong
package
here,
bab-oh
parser!
It.
B
C
Babel
/
parser.
Try
it
that
way.
First,
oh
you're,
probably
right!
Oh
look
at
that.
I
never
use
babble
like
Babel
makes.
You
think
that
you
got
it
right.
That's
why
I
learned
about
Babel
and
and
obviously
you
never
have
it
right?
Oh,
oh,
it
doesn't
have
a
reference
to
this.
So
does
it
have
XML
oops
nope,
but
Babylon
does
so
whatever
they
did
to
to
get.
C
A
It's
another
bizarre
thing
about
this
HTML
comment:
is
that
anything
that
renders
JavaScript
that
produces
a
JavaScript
text
from
an
AST
has
to
be
careful
not
to
accidentally
produce
an
HTML
comment,
because
you
can
have
an
a
AST
that,
if
my
evening
rendered
and
if
naively
printed,
would
actually
produce
HTML
comments.
Grace
yeah.
C
So
I
wasn't
aware
of
the
single
line
comment
you
know,
condition
there
so
to
me:
I've
been
operating
under
this
assumption
yeah
over
here.
They
they
have
it
as
logic
right.
So
I
was
operating
under
the
assumption.
That
I
will
find
it
with
with
multi-line
comments,
but
I
was
proven
wrong,
but
then
Babel
seems
to
not
do
it
declaratively
or
do
it
at
all
and
in
Babel
Purtzer.
A
A
With
regard
to
the
impact
of
this,
in
the
same
way
that
currently
the
SES
shim
or
the
rump
shim
scans
for
the
import,
expression
and
conservatively
rejects
I
think
the
realm
shim
should
also
scan
for
a
sequence
of
characters
that
look
like
an
HTML
comment
and
conservatively
reject
any
text
to
be
evaluated.
That
has
that
sequence
of
characters,
yeah.
C
It's
6033
two
of
those
and
45
which
is
yeah
whatever
okay,
so
so
yeah
I
was
good
to
actually
find
it.
Cuz
cuz,
you
know,
like
I,
don't
really
go
looking
for
these
particular
things,
but
it's
good
raising
it
now
now.
I
have
to
actually
implement
that
too,
but
I'm
not
gonna
worry
about
it.
Now
it
just
yeah,
so
I
want
to
actually
quickly
show
the
draft
that
we
were
putting
together
about
the
Jessie
frame,
because
it's
the
same
architecture
for
SES
right,
great
awesome,
so,
but
so
so
I'm.
C
C
C
C
So
I'm
building
the
resolver
now
which
it's
an
FBA,
so
every
invalid
url
becomes
converted
into
a
hash
and
then
I
use
an
SVM,
a
approach,
but
we
started
to
flesh
out
sorry
F,
a
yeah,
a
single-page
application,
oh
okay,
yeah!
So
like
the
renderer,
the
everything
is
in.
You
know
done
on
the
client
side
from
work
down
files,
basically
okay,
yeah,
so
so
SES
frame
is
still
here.
C
All
I
did
is
you
know,
think
of
a
way
for
me
to
get
rid
of
my
distractions
that
are
not
helping
me,
build
the
foundation
of
SES
frame
itself
and
and
I
guess.
We
came
up
with
an
with
the
interface
of
what
I
would
expect
Jessica
to
provide
in
the
global
scope
of
the
Service
Worker
service
workers
are
notoriously
very,
very
hard
to
debug
the
best
platform
for
debugging
them
is
really
Chrome.
C
The
only
platform
they
don't
have
as
much
trouble
with
is
actually
chromed.
So
if
you
need
to
debug
it
you're
likely
not
going
to
be
in
Chrome
but
long
story
short,
they
only
import
script.
They
don't
have
import
module
support,
at
least
when
my
hopes
were
up
a
few
months
back.
I
was
you
know.
I
I
was
pulled
back
by
this
realization
that
you
know
they
still
don't
support
modules
on.
C
So
we
wanted
to
think
of
what
a
global
method
in
the
serviceworker
would
be
like
if
jessica
and
the
rest
of
the
architecture
are
integrated
and
basically
the
the
architecture
will
have
a
particular
asset
that
it
knows
is
Jessica
bound
resource
that
needs
to
go
through
a
translate
or
a
validate
or
whatever
method.
We
still
don't
know
what
the
methods
we
need
here
will
be,
so
we
just
pick
translate
for
now,
because
we
might,
it
might
be
that
the
code
will
be
compartmentalized
in
some
way.
C
C
So
so,
basically,
this
was
the
important
interface
point
for
integration
between
the
work
I'll
be
doing
in
the
work
that
Michael
is
doing
already,
and
we
talked
about
what
this
object.
The
parameters
object
could
look
like
as
an
early
draft,
and
we
picked
names
that
don't
conflict
with
things
like
source
map,
the
way
they
use
the
word
source
URL
for
instance,
or
or
stuff
like
that,
just
thinking
down
the
road,
if
code
will
be
changed,
code
has
to
be
resource
mapped.
C
These
are
you
know,
complexities
we
don't
want
to
deal
with
now,
but
we
don't
want
to
end
up.
I
ran
into
a
lot
of
problems,
overlapping
the
names
for
source
maps
in
other
areas,
so
so
I
think
the
idea
that
we
ensure
those
to
pick
the
right
names
was
really
the
height
of
our
discussion.
C
C
A
Okay,
this
sounds
like
a
I'm
really
glad.
You
went
through
that
this.
It's
now
256
I
think
this
is
a
good
stopping
point
and
I
actually
have
a
three
o'clock
meeting.
So
kate
has
already
signed
off
and
she's
the
one
who
started
the
recording
solid.
Do
you
know
if
I
kiss
what
how
to
stop
the
recording?
Can
any
of
us
just
hit
a
stop
button
or
can
I
hit
the
stop
button?
I
think.