►
From YouTube: Given at tc53: Omit Needless Words
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
B
C
C
The
title
slide
I
want
to
raise,
but
but
not
revisit
really
during
the
talk
that
the
issue
of
devices
is
not
just
aligned
because
of
smallness
because
of
the
need
to
occupy
less
RAM
and
less
wrong.
It's
also
aligned
I
think
eventually,
because
insecure
devices
can
tell
us
this
group
as
I
understand.
It
is
about
devices
and
wearables.
C
So
the
main
methodology
that
I've
been
pursuing
I
like
to
use
the
phrase,
don't
add
security,
remove
insecurity
that
the
essential
object
computing
paradigm.
That
JavaScript
embodies
quite
well
that
object.
Computing
paradigm
taken
by
itself
is
already
a
very
good
model
of
modular,
secure,
computation,
the
notion
of
memory,
safety
of
object,
encapsulation
of
method
invocation
as
message
passing,
where
the
receiving
object
reacts
to
the
message
only
according
to
its
code
and
where
it
can
only
cause
effects
by
using
references
that
it
holds.
C
These
are
all
perfectly
aligned
with
the
access
control
model,
called
object,
capabilities
and
the
reason
that
our
object
languages
are
not
good
at
security
is
because
of
all
the
additional
stuff.
That's
been
added
beyond
the
core
object
paradigm.
So,
rather
than
adding
a
whole
bunch
of
new
mechanism
for
security,
my
emphasis
has
been
to
add
means
to
remove
the
things
that
cause
the
insecurity
and
to
remove
them
in
an
enforceable
manner.
C
So
I'm
going
to
take
us
and
through
several
subsets
of
JavaScript,
so
that
the
smallest
subset
that
we're
all
is
one
that
we're
all
familiar
with,
which
is
Jason,
which
is
a
tiny
subset
of
JavaScript
whose
emphasises
only
data
and
it's
become
a
universal
format
for
safe
mobile
data
and
part
of
what
makes
it
Universal
is
that
it
is
trivial
to
parse.
So,
no
matter
what
the
language
and
no
matter,
what
the
platform
everybody
felt
empowered
to
go
ahead
and
write
their
own
JSON,
parser
yeah,
it's
not
quite
trivial
to
parse
correctly.
C
So
a
lot
of
the
massive
adoption
of
Jason
were
that
parsers
that
were
slightly
incorrect.
But
that's
often
the
way
massive
adoption
happens
on
the
completely
opposite
side
of
the
scale.
There
is
the
full
atmos
crypt
standard
that
was
constrained
to
be
upwards
compatible
with
all
of
the
legacy
atmosphere,
3
stuff,
that
existed
at
the
time
that
I
joined
the
committee.
So
it
contains
both
strict
mode
and
sloppy
mode
and
sloppy
mode.
Real
is
incredibly
insane
and
really
should
be
thought
of,
as
existing
only
as
an
atmospheric
impaired
ability
mode
with
ECMO
script.
C
Five
came
the
definition
of
script,
which
is
a
saner
subset
and
particular
Sales
Center
subset
that
enables
the
creation
of
the
secure
sense
the
enforceable,
secure
subsets.
So
the
focus
of
the
talk
and
the
focus
of
our
work
in
Cork
will
be
on
SES,
which
stands
for
secure,
Atmos
crypt,
which
takes
advantage
of
the
mechanisms
introduced
with
with
Atmos
crypt
script
and
the
mechanisms
introduced
into
JavaScript
standard
since
then,
so
that
you
can
have
multiple
mutually
suspicious
featherweight
compartments.
C
Whether
in
fact
is
only
one
route
realm.
In
fact,
SES
does
already
successfully
run
with
in
excess
and
then
I'm
going
to
explain
a
very
small
subset
of
SES
named
Jesse,
which
is
intended
to
be
to
serve
a
role
like
Jason,
but
for
Universal,
safe
mobile
code
to
where
jesse
is
a
sufficiently
small
subset
of
SES.
C
That,
in
the
same
sense
in
which
everyone
felt
empowered
to
write
a
jsonparser
in
whatever
language
jesse
is
a
subset
such
that
it
becomes
straightforward
to
write.
A
simple
eval
apply
interpreter
of
Jesse,
no
matter
what
your
language
and
what
your
platform,
so
that
Jesse
becomes
a
format
for
sending
code
with
the
security
properties
of
SES
but
easy
to
interpret
on
any
target
on.
The
alignment
with
this
group
is
that
SES.
C
C
C
C
C
So
so
the
way
harden
works
is
it
isn't
a
transitive
application
freeze
that
does
its
transitivity
by
walking
properties
by
by
traversing
from
property,
to
property,
to
all
the
things
that
are
reachable
just
buy
property
traversal
without
invoking
any
of
the
functions
of
the
object
being
traversed?
So
it
really
is
not
about
immutability.
C
It
is
about
tamper
proofing
surface
so
that
between
mutually
suspicious
objects,
one
subsystem
can
expose
defensible
objects
to
another
subsystem
now,
under
certain
conditions.
When
you
harden
an
object
graph,
you
actually
cause
it
to
become
pure,
and
what
pure
means
is
that
this
definition
comes
from
the
use
in
the
wyvern
language
in
Germany.
C
We
called
it
immutable
in,
but
what
it
means
is
that
there
is
no
mutable
state
or
IO
anywhere
to
be
found
in
that
object
graph
and
therefore
that
object
graph
is
itself
something
that
could
be
placed
in
ROM
without
meeting
the
extra
bookkeeping
for
shadowing
shadowing
those
objects
with
mutations
of
those
objects.
Those
objects
are,
semantically,
have
no
encapsulated
mutable
state
or
I/o
abilities,
and
that's
no
ability
to
be
there
cause
effects
on
the
world
outside
nor
abilities
to
sense
effects
from
the
world
outside.
C
C
So
now
to
take
you
through
the
subsets
that
the
subsets
nest,
the
subsetting,
that
we,
those
of
us
who
understand
the
javascript
in
some
depth,
the
subsetting
that
we
know
well,
is
the
difference
between
the
full
echo
script
standard
versus
the
Ekman
script,
strict
subset
of
the
fault
like
the
script
standard.
So
the
the
things
shown
in
this
Venn
diagram
between
each
control
between
the
echo
script
box
and
the
es
strip
box
are
all
of
the
things
emitted
from
echo
script
to
get
the
ES
stripped,
and
so
that
would
be
following
that
graphic.
C
The
pattern
throughout
and
we're
also
using
horizontal
versus
vertical
I.
Don't
know
if
you
guys
can
see
this
based
on
where
the
zoom
control
is,
but
the
horizontal
arrow
at
the
top
of
the
screen
is
labeled
semantics
and
the
vertical
arrow
on
the
left
side
of
the
screen
is
labeled
syntax.
So
we're
going
to
be
using
horizontal
and
vertical
in
order
to
in
order
to
notate
the
difference
between
semantic
subsetting
and
syntactic
subsetting.
C
So
the
full
ACMA
script
standard
contains
width,
that's
a
syntactic
element
that
is
statically
omitted
from
Atmos
Crips,
x1,
sorry
for
magma
scripts.
Strict
and
the
full,
like
my
script
standard,
contains
the
crap
on
the
right
that
I
won't
go
into
unless
anybody
has
a
question.
But
those
are
the
elements
from
sloppy
mode
that
are
omitted
to
make
Heckman
scripts
print
mode.
C
Three
main
concepts:
one
is
this
issue
of
the
primordial.
Let
me
define
primordial
primordial
are
all
of
the
objects
that
are
mandated
to
exist
before
code
starts
running,
except
for
the
global
object
for
reasons
that
will
become
clear.
We
omit
the
global
object
itself
from
our
definition
of
primordial
x',
but
object
array
object,
our
prototype
right,
prototype,
arrayed,
that
prototype
dot
push
and
all
of
the
other
method
objects,
so
that
whole
object
graph
of
objects
that
exist
before
code
starts
running.
C
Those
are
all
try
more
deals
and
when,
according
to
standard
Eggman
script,
including
heck,
no
scripts
strict,
those
are
all
mutable,
those
can
all
be
mutated
and
therefore
the
excess
engine
when
just
running
standard
JavaScript,
has
to
pay
tremendous
bookkeeping
overhead
to
enable
any
of
them
to
be
mutated.
Even
though
almost
all
programs
never
mutate
any
primordial,
in
which
case
all
of
that
bookkeeping
is
essentially
wasted,
space
and
wasted
time
to
go
through
the
extra
bookkeeping.
Every
time
you
access,
a
property
is
also
costly
at
runtime.
C
Standard
primordial
z--,
primordial
Global's,
like
array
and
object
and
function
and
Jason
etc,
but
it
also
contains
host
provided
Global's
like
in
the
browser
window
and
document,
an
XML
HTTP
request
in
node
process
and
require
and
then
through
require
various
modules
that
give
access
to
the
file
system.
So
these
are
basically
sources
of
authority
sources
of
the
ability
to
cause
effects
on
the
outside
world,
which
all
code
has
access
to,
because
all
code
has
access
to
it.
C
C
The
global
object
is
the
one
that
has
the
bindings
for
the
the
elements
of
the
primordial
that
have
global
names
and
then
among
the
prime
orioles
that
we
distinguish
to
perfect
or
kinds
which
are
the
evaluators
which
evaluate
code
in
a
scope
where
the
free
variables
in
that
code,
the
the
variables
that
are
used
in
the
code,
but
not
defined
in
that
code,
are
instead
looked
up
in
the
global
object.
So
evaluators
are
scoped
to
some
global
object.
C
So,
where
Eknath
scripts
strict
has
pure
has
mutable
prime
Oracle's
secure,
atmos
crypt
has
pure
primordial
and
what
I
mean
by
pure.
We
cause
them
to
be
pure,
mostly
by
applying
Harden,
but
one
of
the
things
that
we've
done
over
the
entire
time,
starting
with
Atma
script.
Five
is,
with
the
exception
of
with
a
very
small
number
of
grandfathered
bits
of
implicit
mutable
state
which
we
can
ignore
for
present
purposes.
With
the
exception
of
those
grandfathered
bits,
we
have
constrained
the
primordial
'z,
so
there
is
no
hidden
mutable
state
such
that.
C
If
you
harden
the
primordial
's
the
primordial
become
pure
and
therefore
Rama,
Bob,
so
secure,
Atmos
crypt
has
all
the
primordial
czar
pair
and
instead
of
having
one
global
object
for
the
realm
as
a
whole.
Rather
we
have.
We
have
our
ability
to
create
compartments
where
each
compartment
has
its
own
global
object.
C
C
For
those
who
don't
know
about
decorators,
I
won't
explain
them
here,
but
the
point
of
a
defensible
class
is
again
a
hardened
API
surface.
A
defensible
class
is
like
a
normal
class
except
the
constructor,
the
prototype.
All
the
methods
on
the
prototype
are
all
frozen,
so
the
transitive
API
surface
of
the
constructor
itself
is
hardened
and
in
addition,
the
instances
made
by
the
class
or
hired
that
does
not
for
the
class
as
a
whole.
If
there's
no
hidden
static
state,
which
is
typical
for
classes
hardening,
the
class
makes
the
class
here
for
the
instances.
C
C
C
In
SES
we
initially
defined
defined
us
through
the
the
original
frozen
rounds
proposal
where
the
primordial
start
out
frozen
and
what
we
found
was.
There
is
one
kind
of
code
which
font,
which
does
exist
and
is
important
and
is
now
considered
to
be
a
code
which
is
part
of
best
practice
which
are
shims
shims
that
run
ahead
of
time
and
customize
the
environment.
C
C
Customization
can
then
be
snapshot,
snapshot
had
placed
and
wrong
so
that
only
the
things
that
are
different
afterwards
become
the
things
that
need
to
be
need
to
reside
in
rent
so
now
I'm
using
the
gray
background
to
indicate
the
objects
that
are
placed
and
wrong.
So
in
this
case
the
full
set
of
primordial
x'
are
placed
in
ROM
are
completely
frozen
and
pure
and
the
the
objects
that
are
don't
have
the
gray
background
are
in
these
yellow
boxes,
each
of
which
is
a
compartment.
So
a
compartment.
Each
compartment
has
its
own
pertinent
global.
C
The
evaluators
for
the
compartment,
the
eval
function
and
the
function.
Constructor
are
evaluate
code
only
within
the
scope
of
that
compartments
global
and
these
compartments
all
inherit
from
the
same
set
of
primordial.
So
they
can
so.
The
code
with
loaded
in
different
compartments
can
be
put
in
contact
with
each
other
and
interact
perfectly
well,
and
if
they
harden
their
API
surface
before
they're
put
in
contact,
they
can
also
defend
each
other
from
each
other's
misbehavior.
C
Even
when
a
hardened
object
is
not
pure
I
want
to
emphasize
that
that
itself
reduces
the
need
for
runtime
bookkeeping,
because
the
properties,
the
data
properties,
are
now
only
writable.
They
are
not
configurable
and
therefore
there
is
much
less
bookkeeping
needed
in
order
to
provide
for
the
runtime
representation
of
a
non
configurable
mutable
data
property.
C
C
Okay,
so
back
to
our
subsetting
diagram.
So
the
elements
that
are
in
the
yellow
or
the
light
green
are
the
elements
of
secure
at
the
script,
which
enable
tremendous
amounts
of
existing
JavaScript
code,
that
obeys
best
practices
to
run
as
SAS
code
and
the
experience
both
at
Google
with
Google
kaha,
which
contained
the
earlier
version
of
SAS
and
today
with
a
Salesforce
that
is
running
a
five
million
developer
ecosystem
on
top
of
the
modern
version
of
SAS.
C
Both
of
those
experiences
as
well
as
our
experience
and
so
far
at
gorrik,
which
granted
are
currently
at
a
much
smaller
scale,
but
all
of
those
experiences
verify
that
leaving
aside
trusted
shims
for
doing
a
pre
freeze,
customization
of
the
environment,
that
a
that
aside
from
those
a
tremendous
amount
of
existing
JavaScript
code,
that
obeys
best
practices,
runs
in
SAS
and
therefore
can
be
separated
and
protected
from
each
other.
Through
the
means
already
explained.
C
Now
jesse
is
intended
to
be
a
tiny
subset
of
SES
that
is
not
intended
to
support
existing
legacy
JavaScript
code.
So
all
of
the
elements
in
yellow
and
light
green,
we
remove
them
to
make
Jessie,
and
that
includes
some
elements
of
the
SES
runtime,
including
property
reflection,
various
things
that
make
implementing
Atma
script
burdensome
and
most
radically
of
all
secure.
C
C
C
C
C
Strangely
Jessie
emits
proxy
itself
because
proxy
is
hard
to
implement,
but
proxy
and
weak
map
were
introduced
into
JavaScript
in
order
to
support
the
creation
of
membranes
so
Jessie,
while
emitting
the
proxy
will
directly
have
as
part
of
its
available
runtime
a
membrane
library,
because
that
is
very
supportive
of
security
patterns
and
in
a
standalone,
Jessie
environment
where
all
objects
are
hardened.
The
subset
of
the
member
of
membrane
concepts
which
are
meaningful
in
a
standalone
Jessie
environment
are
easy
to
implement.
C
C
So,
returning
to
our
console
our
concepts
of
hardened
and
pure
in
order
to
explain
our
modules,
we
need
to
the
modules
admitted
into
Jesse,
as
well
as
most
of
the
modules
that
will
be
useful
in
SES.
The
key
thing
is
to
write
modules
in
a
form
that
is
statically
verified
as
purifying
to
actually
harden
every
exported
value
of
every
module
by
explicitly
using
harden.
Even
though
harden
is
a
very
nice
abstraction
over
object
up
freeze,
it
is
still
notationally
awkward,
it's
officially
notational
in
awkward
that.
C
So
instead
we
define
the
solution
of
purifying
and
a
notion
of
a
pure
loader,
so
modules,
export
and
import
and
a
pure
loader
is
one
where,
in
order
for
a
module
to
be
loaded
by
a
pure
loader,
the
module
has
to
have
passed
a
static
verification
that
it
is
purified
and
what
purify
Abul
means.
I'll
just
I'll
give
the
definition
first
and
then
I'll
unpack
it.
C
What
purifying
means
is
under
the
assumption
that
everything
the
module
imports
is
pure
and
that
everything
of
the
module
exports
is
hardened
by
the
loaner,
that
the
consequence
is
that
everything
the
module
exports
is
actually
pure
and
therefore
any
other
purifying
module.
Importing
from
this
module
is
important,
only
pure
values.
C
C
However,
the
the
modules
are
the
wiring
between
modules
between
the
export,
the
imports,
the
exit
of
the
imports
of
one
being
wire
to
the
X
printed.
Another
goes
through
a
learner
and
the
learner
can
intervene
on
the
values
that
it's
wiring
from
one
module
to
another.
So
without
any
further
explanation,
we
can
see
that
make
point
itself
if
hardened
by
the
loader
as
an
exported
value
becomes
pure
because
the
function
closed
is
closes
over
no
assignable
variables
and
in
and
in
this
case
it
closes
over
no
variables.
C
Harden
itself
is
understood
as
a
special
case
by
the
static
checking.
If
it
did
close
over
any
variables,
we
would.
We
would
need
to
ensure
statically
that
the
variables
were
not
signed
to
and
that
the
variables
were
themselves
initialized
only
to
pure
values,
not
to
purify
all
the
values
but
to
actually
pure
values.
C
Now,
at
the
bottom,
we
import
the
value,
excess
xx
from
a
few,
a
few
module,
since
the
assumption
is
that
were
being
loaded
through
a
pure
loader
that
enforces
that
it's
only
loading
purify,
abbu
modules
and
it
hardens
all
of
their
exports.
We
can
assume
here
that
XS
X
X
itself
is
a
pure
value
and
then,
through
our
static
checking
rules
in
this
case-
and
this
is
where
the
checking
rules
get
admittedly
delicate-
we
can
because
make
point
is
defined
within
the
same
module.
C
C
I
think
that
is
the
end
of
my
prepared
talk.
There's
lots
and
lots
of
concepts
here
and
I
now
prepared
for
questions
and
discussion.
A
Thank
you
mark.
That
was
a
lot.
It's
great
I
mean
very
it's
good.
It's
it's!
The
third
or
fourth
time,
I've
been
through
this
material
in
various
forums
and
I'm,
starting
to
starting
to
feel
comfortable
with
it.
It's
it's
I'm.
Joking
for
questions.
You
and
I
have
had
a
chance
to
discuss
this
before,
but
other
other
folks
may
have
something
to
say.
D
I
think
one
of
the
things
I
liked
about
the
word
that
I
witness
the
last
two
days
and
just
as
I
read
up
on
your
October
minutes,
I
think
which
made
this
group
so
effective.
Is
it
where
there's
a
existing
industry
metaphor
paradigm
that
can
be
applied,
that
it's
easily
understood,
University,
understood
both
in
context
and
syntax
to
adopt
it?
And
my
question
is
just
is
how
consistent
is
this
in
approach
and
is
there
a
competing
approach
that
you
would
consider
for
security.
C
C
There
is
no
competing
approach
to
the
approach
taken
here
that
provides
anything
like
the
level
of
security
that
this
provides.
Now.
This
is
not
uniquely
the
owner
by
the
approach.
What
I
mean
is
the
object
capability
approach,
also
in
particular,
of
the
transition
from
atma
script
script
to
SES,
that
there
are
many
other
approaches
to
security
that
have
tremendous
things
to
say
to
them.
C
Now
some
of
those
can
be
combined
with
object,
capabilities
and
SES
is
not
uniquely
the
only
way
to
get
from
es
strict
to
object
capabilities.
So,
with
regard
to
a
lot
of
the
particular
design
decisions
to
get
from
es,
strict
to
object,
capabilities
and
there's
a
design
space
there
and
we
made
a
bunch
of
choices.
I
am
not
aware
of
anything
out
there
that
is
trying
to
provide
object,
capabilities
for
modern
Atmos,
cripts,
strict,
which
is
a
competitor.
The
key
phrase
in
there
was
modern.
C
The
old
SES
in
google
kaha
was
defined
mostly
as
a
object,
ability
subset
of
Atma
script
5
and
has
led
to
other
work
and
both
if
and
some
of
that,
other
work
does
show
somewhat
other
ways
to
get
from
Atma
script.
Strict
to
SES
that
nobody
has
attempted
to
reproduce
any
of
those
for
modern
JavaScript.
C
E
F
F
C
The
so
work
so
I
put
pure
modules
into
the
Jessie
box,
but
not
the
essence,
but
the
SES
box
supports
modules
that
are
not
pure
we're
working
now,
but
are
still
in
a
perk
apartment
basis,
so
we're
working.
This
is
work
in
progress
with
the
the
SES
group
that
Salesforce
and
node
and
GoDaddy
and
several
other
players
are
all,
are
participating.
A
meta
mask
in
this
SES
group
and
our
main
topic
is
the
safe
module
system
for
wiring
up
and
propagating
through
initial
Authority
in
a
way
that
enables
the
programmer
to
express
least
authority.
C
Necessarily
easy
encouraged
over
script
because
of
the
pervasive
access
to
the
genuine
global
object
and
therefore
to
all
authority.
This
is
our
test
case
for
designing
a
system
that
can
support
legacy
code
and
provide
individual
modules
and
individual
packages
with
least
Authority.
So
the
way
we
do
that
is
partially
through
a
manifest.
C
That
says
how
different
packages
can
be
wired
to
each
other,
which
is
basically
a
constraint
on
the
import
graph,
as
well
as
a
partial
redirection
of
that
import
graph.
So
very
concretely,
if
module
foo
import,
does
a
import
or
require
I'm
not
going
to
distinguish
important
require
because
we're
looking
at
node
code
right
now,
so
things
that
are
expressed
that
we
that
would
be
expressed
in
import
or
currently
expressed
as
requires
so
something
that
requires
FS.
C
Likewise,
the
per
compartment
Global's.
You
can
redirect
the
definition
of
the
values
of
global
variables
through
attenuating
modules,
as
stated
by
the
manifest,
so
the
manifest
can
work
with
legacy
code.
But
the
basic
idea
is
that
each
compartment
becomes
a
separate
protection
domain
that
is
populated
with
the
least
authority
needed
by
the
package
loaded
into
that
compartment.
G
C
Goreck
my
company
is
as
well
as
meta
mask,
who
are
participating
in
the
working
group,
are
both
looking
to
use
this
in
the
blockchain
ecosystem.
In
the
case
of
boric,
we
use
it
we're
looking
at
it
in
a
node
like
manner
to
run
on
the
server
side
on
top
of
block
trains
themselves
in
the
meta
mask
case,
they're,
looking
at
it
primarily
for
the
browser
side
up
for
creating
a
sick,
a
secure
user
interface
system
for
interacting
with
distributed
application.
These
applications
that
are
themselves
running
on
existing
blockchains.
C
C
G
G
A
So
mark
I
am
I
wanted
to
ask.
Maybe
a
slightly
practical
question.
Out
of
all
this
I
was
I
was
interested,
particularly
by
your
comment
that
you
have
some
experience
with
SES
in
the
wild,
using
through
sales
force
and
if
I
recall
well,
what
you
said
is
that
you
characterized
it
as
the
majority
of
kind
of
well
written
code,
nothing.
C
C
A
That's
very
think
the
clarification
is
helpful
so
where
I
was
where
I'm
going
with?
That
is
this.
This
committee
is
embarking
on
what
is
effectively
a
new
target,
and
so
we
have
I
can
safely
say
relatively
little
legacy
code
compared
to
the
web
to
deal
with,
and
so
there's,
as
you
were
talking
the
question
sort
of
arose
in
my
mind.
If
we
optimistically
assume
that
SES
exists,
you
know
down
the
road
as
part
of
the
standard.
A
C
A
C
C
C
C
That
is
not
that
assumes
a
abstract
object
model
as
it's
a
code
model
of
what
it's
proving
properties
about
and
is
really
focused
on
the
mechanism
of
specification
and
proof.
But
we
believe
that
it
can
be
composed
with
Jessie
eventually
in
order
to
provide
mechanized
proofs
of
interesting
security
properties
of
Jessie
programs.
A
Okay,
excellent,
so
it's
an
intriguing
backing
up
a
little
bit.
It's
a
very
intriguing
thought
that
that
there
may
be
a
subset,
that's
an
appropriate,
an
appropriate
one
for
us
to
look
at
will
lemon
well
I
think
we
all
have
some
homework
to
do
just
to
catch
up
on
what
that
would
look
like
in
the
implications,
but
very
much
appreciate
the
introduction.
Today,
Rick,
you
were
holding
something
up
to
the
screen
and
I
didn't
look
soon
enough.
I
just
wanted
to
check.
If
you
have
anything
you
want
to
add
before
we
close
out
this
topic.
B
My
notes
right
down
shouldn't,
we
require
strict
mode.
Then
I
wrote
no
script
target,
only
a
module
target
and
then
eventually
I
wrote
SES
and
put
a
big
circle
around
for
exactly
the
reason
Peters
that
you
said
it's
it's
very
nice
to
to
be
able
to
unburden
ourselves
from
the
1j
s
doctrine
right,
which
is
to
say,
like
we're,
not
we're
not
gonna,
like
disable
break
things
that
have
existed
forever
because
there's
this
world
of
code.
You
know
extant
software.
That
must
continue
to
run
properly
on
some
bank
somewhere
in
some
time.
B
So
it
seems
to
me
that
that
we
should
take
the
opportunities
to
create
a
both
expressive
platform,
but
also
secure
platform,
and,
as
I
said
yesterday,
you
know
I've
been
on
tc39
a
delegate
to
the
committee
since
2012,
so
I've
been
working
side
by
side
with
mark
in
that
time
and
I've
come
to
have
a
great
deal
of
respect
for
the
work
that
mark
does
and,
more
importantly,
the
the
approach.
The
strategy
that
he
takes,
which
is
I,
was
summed
up
very
nicely
in
this
slide
that
you
had
early
on,
which
was
don't
like.
B
B
You
know
I
mean
like
just
like,
even
even
if
it
turns
out
that,
like
obviously
we
need
to
experiment
with
this,
like
put
it
out
there,
we're
not
gonna,
make
any
decision
rashly
or
prematurely
but
I'm
saying
that,
even
if,
even
if
we
find
ourselves
in
a
position
where,
like
maybe
it's
too
restrictive
for
what
reason
I'm
not
saying
that
that
is
even
a
scenario
that
we
will
encounter.
Just
hypothetically
I
see
no
reason
why
we
couldn't
and
like
make
rules
that
say
of
strict
mode.
Only.
You
know
like
this.
B
B
E
C
It
is
not
yet
stated
in
in
a
manner
appropriate
for
bringing
as
a
proposal,
but
I
would
love
to
bring
it
as
a
proposal
and
with
regard
to
for
Jesse
itself,
whether
it
should
go
to
tc39
or
TC,
53
or
somewhere
else.
I.
Don't
have
a
strong
opinion
on
that
I'm,
so
your
advice
is
solicited,
but
the
natural
thing
for
me,
just
based
on
my
history,
would
be
to
bring
Jesse
as
a
proposal
to
tc39.
C
Is
not
inaudible
things
with
existing
JavaScript
code?
It
is
a
subset
of
the
outer
parts
of
the
onion,
so
anything
so
anything
written
in
Jesse
will
run
as
SES
and
any
correct
jesse
program
by
the
deafened
by
the
peculiar
definition
of
correct
Jesse
will
still
run
correctly
when
run
as
an
SES
program.
So
we
have
that
direction
of
compatibility,
but
there's
essentially
zero
existing
JavaScript
code,
which
will
run
as
a
jesse
program.
E
Okay,
so
then
I
have
a
last
question
and
then
probably
also
the
time
is
over.
So
so
practically
you
are
restricting
use
as
you
go
more
inside
on
the
of
the
onion.
Yes,
so
is
there
really
any
any
any
any
issue
regarding
performance
or
any
other
restriction
that
for
instruction?
You
have
a
code
in
Jesse
and
in
comparison
with
a
with
a
code
which
is
outside
in
the
in
the
onion,
but
it
is
not
so
secure.
So.
C
One
is
that
the
mechanism
we're
using
to
intercept
global
scope
references
so
that
we
can
do
a
per
compartment.
Global
object
is
a
width
or
a
proxy
and
we're
doing
a
mechanism
to
make
that
efficient
in
the
typical
case.
But
when
there
is
this
optimization
mechanism,
but
when
a
global
variable
reference
misses
the
optimization
misses
essentially
the
optimizing
cache,
which
happens
quite
often,
there's
a
substantial
overhead
of
going
through
the
proxy
mechanism,
with
SES
directly
supported
by
the
platform
rather
than
as
a
shim.
That
overhead
goes
away.
C
The
other
source
of
overhead
is
the
override
mistake,
and
that
is
irritating.
It
is
not
so
irritating
as
to
be
a
impediment
to
practical
use.
A
Salesforce
is
is
in
deployment
with
paying
the
both
of
these
costs
and
they're
not
finding
either
of
these
costs
to
be
an
impediment,
practical
use.
There
is
a
proposal
before
the
tc39
committee
to
fix
the
override
mistake
in
the
standard,
and
if
that
happens,
then
that
source
overhead
goes
away.
However,
it's
not
known
how
web
compatible,
that
is,
if
in
TC
53,
we
can
somehow
MIT.
C
We
can
somehow
allow
ourselves
to
run
SES
with
the
override
mistake
fixed.
Then
again,
that
should
be.
That
should
have
no
cause
of
overhead,
so
taking
care
of
those
two
there's
one
remaining
source
of
overhead.
That's
worth
calling
out
explicitly,
which
is
the
objects
as
closure
pattern
for
expressing
objects,
has
an
allocation
cost
and
therefore
a
round
call.
So
it's
quite
relevant
to
this
committee,
where
you
have
to
allocate
a
closure
per
method
per
instance.
C
Now
my
language
and
a
previous
proposal
that
I
had
made
it
to
the
ACMA
script
committee
back
in
the
transition
days
from
Atma
script,
five
Tecna
script,
six
shows
that
it
is
possible
to
implement
objects
as
closure
without
that
space
overhead,
but
it
requires
some
re-engineering
of
the
object
runtime.
With
the
current
object.
Runtimes,
you
have
the
allocation
cost
of
a
method
of
a
allocating,
a
closure
per
method
per
instance
that
significant
Ram.
C
It
is
not
significant
runtime
for
object
for
object,
abstractions
that
are
written
well
and
but
what
I,
but
that's
a
weighted
definition
of
well.
What
I
mean
by
written
well
is
object,
abstractions
that
don't
have
a
tremendous
number
of
methods
in
the
equivalent
of
the
single
class,
but
rather
have
lots
of
small
classes,
each
of
which
have
have
small
numbers
of
methods.
A
Excellent
so
again,
thank
you
Mark,
it's
I
mean
it's
a
it's
tremendous
to
have
have
an
opportunity
to
hear
you
present
this
and
get
the
ideas
kind
of
firsthand
from
you
in
front
of
this
group
and
good
news
for
you.
Our
next
meeting
in
four
months
is
scheduled
to
be
in
the
valley,
so
we
we
may
be
able
to
follow
up
in
person
all
right
anyway.
I'm
sure
we'll
be
talking
various
points
between
now
and
then
so.
Thank
you.
You're.