►
Description
This is the history of the best feature ever added to a programming language, with particular emphasis on E and JavaScript. We will also consider a functional approach to managing concurrency and distributed programming.
A
Could
you
share
a
little
bit
about
your
background
and
and
could
you
actually
explain
what
hardened
javascript
is
for
those
who
are
listening?
Who
may
not
know
what
the
term.
B
Yeah
so
hard
into
javascript
is
javascript
but
hardened
right,
okay,
yeah!
So
so
my
what
I,
what
I'd
like
to
do
with
my
time,
is
to
take
you
all
web
developers
from
probably
your
starting
position,
which
is
javascript.
Isn't
that
sort
of
inimical
to
security?
Isn't
security
kind
of
impossible
in
that
language?
Isn't
it
really
hard
to
wait?
B
No,
this
is
the
one
most
obvious
popular
programming
language
to
use
for
this
purpose,
so
yeah
so
hardened
javascript
is
javascript,
but
it
had
with
some
additional
features
that
we've
baked
in
in
order
to
lock
down
the
environment,
to
make
it
less
vulnerable
to
prototype
pollution
attacks
and
a
number
of
other
things
and
basically
build
a
platform
for
what
we
call
object,
capability
programming,
which
is,
which
is
simply
if,
if
you
can,
the
only
way
to
do
a
thing
is
to
be
given
a
reference
to
a
thing
that
can
do
it
and
that
sort
of
gives
us
as
programmers
a
foundation
to
stand
on
for
making
making
inferences
about
how
secure
our
system
is.
A
Oh
it
does
it
does
so,
do
you
have
a
do
you
want
to
be
how
how
would
you
like
to
give
your
presentation.
B
Yeah,
I
I
have.
I
have
some
material
to
cover
it's
about
20
minutes
and
if,
if,
if
you
want
to
interrupt
or
if
anybody
in
our
in
our
peanut
gallery,
wants
to
interrupt
along
the
way
to
ask
a
question
or
clarification
or
dig
in
that's
fine
by
me,
so
I'll
just
go
to
town
yeah.
So
so
what
is
hard
javascript,
so
javascript
provides
this
highly
malleable,
scripting
environment.
B
That
makes
it
possible
to
run
programs
that
were
written
by
strangers
on
your
behalf,
right
so
like
in
a
web
browser.
We
are
running
programs
that
were
written
by
strangers
on
our
own
machine
and
we
want
to
be
safe
when
we
do
that
and
javascript
was
designed
for
this
kind
of
kind
of
thing
right
and
we
have,
and
the
reason
why
we
do
this
is
is
it
goes
back
a
really
long
way.
B
We
have
a
really
long
tradition
in
software
of
building
systems
that
increase
interactivity
with
the
user
by
sending
programs
to
the
user
instead
of
just
sending
data
and
like
if
you
go
back
to
the
vt100,
100
terminal
and
the
earliest
web
browser.
I
think
that
you
could
make
an
argument
that
anytime
you're
installing
an
app
on
anything
on
your
desktop
on
your
phone.
B
The
reason
you're
doing
that
is
that
the
app
can
intermediate
between
you
and
and
and
some
service,
and
by
doing
that,
you
kind
of
are
putting
yourself
in
a
position
of
vulnerability
to
the
person
who
wrote
that
program
and
and
the
web
takes
this
very
seriously
apps
and
app
stores
that
take
it
a
little
bit
more
seriously,
but
in
general
you're
putting
yourself
in
a
position
where
you
could
be
installing
a
virus
on
your
computer
and
you
need
to
have
a
platform
that
makes
it
safe
to
do
that
and
javascript
was
designed
to
do
that.
B
So
this
is
to
have
interactivity.
We
need
to
be
able
to
run
other
people's
programs
but
running
other
people's
programs
is
dangerous
and
some
people
even
tell
you
that
you
really
shouldn't
I'm
here
to
tell
you
that
you
can
and
you
can
use
hard
javascript
to
make
javascript
safe
for
this
kind
of
for
the
kinds
of
things
that
we're
writing
smart
contracts
for
and
by
way
of
a
metaphor
in
the
odyssey.
B
You
might
remember
that
odysseus
encounters
the
sirens
who
are
these
dangerous
creatures
who
live
on
an
island
and
the
the
way
the
way
that
they
they
lure.
B
They
lure
sailors
on
to
crash
into
the
rocks
on
the
edges
of
their
island
by
singing
them
a
song
and
the
song
takes
over
their
minds
and
makes
them
so
they
all
of
these
sailors,
just
jump
off
of
their
boats
and
swim
onto
the
island
and
drown,
and
this
is
of
course,
like
a
classical
metaphor
for
running
strangers.
B
Programs
off
of
the
internet
right,
but
but
what
we
want
to
be
able
to
do
is
just
to
listen
to
those
songs
and
enjoy
them
and
understand
them
without
giving
the
sirens
control
of
our
motor
functions
right.
And
so
how
do
you
do
that?
Why
do
and
and
why
do
you
do
it
with
javascript?
Well,
it's
no
accident.
We
used
we've
made
javascript
for
this
purpose.
It's
designed
to
run
sandboxes
and
the
idea
so
like
in
a
web
browser,
though
the
interaction
model
is
that
you
have
it's
it's
yours.
The
parties
involved.
B
Are
you
yourself
and
to
the
person
who
wrote
this
program
right
and
you're
when
you're
running
this
program,
you're
making
yourself
when
you're
running
this
program,
you're,
making
yourself
vulnerable
to
the
stranger
who
crafted
up
the
web
page
and
javascript?
Being
this
highly
malleable
programming
language
makes
it
possible
to
invite
those
programs
to
run,
but
it
only,
but
it's
based
off
of
this
rapidly
deteriorating
fiction
that
the
only
interested
parties
between
involved
in
a
web
application
are
the
the
user
and
the
author
of
the
program.
B
That's
simply
not
true,
anymore,
hasn't
been
possibly
ever
right,
because
you
have
your
there's
the
the
service
there's
the
vendors
who
provide
data
and
services
to
the
service,
so
they
can
do
something
work
to
work
for
you
there's
and
there
are
the
attackers
to
that
service
as
well
and
like
if
you
have
an
advertiser
or
if
you
have
some
some
data
service
provider.
B
All
of
those
people
are
are
involved
in
providing
your
application
up
and
really
the
one
thing
that
you
that
you're,
like
you,
probably
have
a
blind
spot
for,
is
that
all
of
that
software
has
dependencies
and
is,
and
so
those
dependencies
are
an
attack
vector
that
all
of
these
programs
are
vulnerable
to.
B
So
so
the
idea
that
there
are
only
two
parties
in
the
web
page
and
that
this
interaction
model
of
just
the
user
agent
and
the
and
the
author
of
the
of
the
program
are
the
only
only
things
that
need
to
be
sandboxed
is,
is
just
false.
So
how
do
you
get
around
that?
Well,
the
way
you
get
around
that
is
by
hardening
javascript
and
javascript,
of
course,
has
benefited
tremendously
from
how
malleable
it
is
right.
B
It
has
made
it
possible
for
the
language
to
evolve
without
significant
backward
incompatible
changes
for
decades,
but
that
malleability
is
what
makes
it
vulnerable
to
things
like
prototype
pollution
attacks,
and
so
what
we
do
with
hard
javascript
is
we
use
that
pervasive
malleability?
We
have
in
the
language
to
and
turn
it
in
on
itself
right.
B
So
we
take,
we
take
javascript
and
we
use
the
primitives
that
we
have
laying
around
to
turn
it
into
a
language
that
is
not
vulnerable
to
those
kinds
of
attacks
and
also
makes
it
suitable
to
invol
invite
multiple
parties
to
interact
and
even
to
interact
in
object-oriented
ways
that
the
typical
programmer
can
can
understand.
B
So,
but
some
of
the
things
that
javascript
has
baked
in
from
the
beginning
are
super
useful
for
our
purposes
right.
So
a
javascript
program
has
memory
safety,
which
means
that
you
can't
wander
around
in
memory
looking
for
pointers
to
powerful
objects
and
like
if
you
have
a
kernel
function
from
your
operating
system,
it
isn't
necessarily
exposed
to
javascript
in
order
to
call
a
function.
You
need
to
have
a
reference
to
a
function
that
calls
the
kernel
function
and
you
can
deny
you
can
deny
programs
access
to
just
about
any
powerful
capability.
B
The
then
the
other
thing
about
javascript
is:
has
this
lexical
scoping
right?
So
if,
if
I
were
to
write
a
function
in
a
closure,
I
can
have
private
data
within
that
closure
and
the
language
guarantees
that
outside
of
that
object,
that
that
those
references
are
not
accessible.
Unless
you
write
a
program
that
explicitly
grants
whomever
calls
a
function
and
access
to
that
reference
and-
and
so
even
though
javascript
wasn't
born
really
suitable
for
co-tenant
programs.
It
has
this
strict
mode
which
eliminates
features
like
arguments.
B
The
arguments
object,
which
would
have
exposed
dynamic,
scoping
problems
being
able
to
see
who
called
you,
etc.
All
the
way
up
your
scope
chain
and
manipulate
your
arguments,
so
hardening
involves
using
the
strict
mode
feature
which
is
about
10
years
old,
now
and
and
now
and
then
about
10
years
old
10
years
ago.
They
all
with
with
champions
like
our
own
mark
miller.
We
added
object,
freeze
and
object
property
descriptors
to
the
language
makes
which
makes
it
possible
to
make
an
object
its
surface
tamper-proof.
It
can
still
have
mutability
behind
the
scenes.
B
But
if
I
take
this
object
and
give
it
to
two
different
people,
they're
not
going
to
be
able
to
use
that
to
talk
to
each
other
if
they're
not
intended
to
be
able
to
talk
to
each
other,
they
won't
and
and
making
things
like
the
array.
Prototype
tamper
proof
is
what
makes
hardened
javascript
in
safe
against
prototype
pollution
attacks.
B
So
what
we?
What
we
want
to
do
is
be
able
to
have
the
server
run,
programs
that
the
user
has
authored
and
the
way
we
make
this
safe,
typically
is
by
using
hobbled
programming
languages
that
don't
really
give
you
a
lot
of
capability
like
like
sending
a
sql
program,
for
example,
and
even
that's
a
bad
example,
because
sql
itself
is
is
quite
powerful.
B
So
what
we
want
to
do
is
be
able
to
send
a
javascript
program,
but
then,
but
using
this
naive,
malleable,
javascript
and
just
using
eval
for
a
stranger's
program
is
obviously
silly
because
that
program
can
read
the
database
from
this,
which
is
probably
a
variable
in
the
scope
of
the
query.
It
can
call
any
method
of
any
object.
It
can
modify
anything
in
the
prototypes.
B
B
So
hardened
javascript
provides
alternative
solutions
to
this
problem,
so
in
hardin
javascript
you
can,
you
can
use
a
different
set
of
evaluators
and
contrary
to
popular
popular
wisdom,
eval
isn't
evil,
and
this
is
easily
proven,
because
the
levenshtein
difference
between
eval
and
evil
is
one.
That's
that's
not
zero.
That
means
they're
not
the
same,
but
that's
a
bit
of
a
stretch,
I'll
admit
there.
B
B
It
can
do
weird
things
like
introduce
variables
in
the
caller's
scope
to
overshadow
things
that
they
have
and
if
you
go
back
to
that
classical
metaphor,
this
would
be
like
giving
this
the
sirens
the
ability
to
decide
what
undefined
means
for
every
program
that
shares
that
scope.
Then
then,
after
that,
there's
something
a
lesser
eval.
If
you
will
that's
indirect
eval.
B
This
is
a
minor
reformation
of
evaluated
added
late
to
the
language
that
allows
you
to
take
eval
and
use
it
in
any
way,
except
for
as
a
a
function
like
you
can
you
have
to
rename
it
or
capture
it
in
an
expression
or
something
like
that
in
that
case,
instead
of
being
dynamically
scoped,
it
reads:
it
reads
off
of
the
global
scope
instead
and
this
helps,
but
it's
clearly
not
enough,
then
there's
another
subtle,
eval
function,
constructor
and-
and
this
is
the
subtle
eval
that
allows
you
to
run
a
function
body
and
global
scope,
but
even
then
you're
still
pr,
even
with
we've.
B
Even
with
this
subtle
e-value,
there's
a
you're
vulnerable
to
a
whole
bunch
of
things,
including
prototype
pollution
attacks.
There
are
a
lot
of
ways
to
subvert
it,
so,
instead,
what
we
do
is
we
use
hardened
javascript
now
hardened
javascript
is
kind
of
like.
B
If,
if
you
remember
another
classical
thing
gall,
it's
like
gall,
because
it's
divided
into
three
parts,
it
has
a
lockdown
function,
a
hardened
function
and
a
compartment
constructor,
and
then,
with
these
three
devices,
lockdown,
which
prepares
an
environment
and
makes
its
print
makes
the
environment
immutable
hardened,
which
allows
you
to
defend
your
own
objects
and
apis
and
compartments
which
create
evaluators
that
are
isolated
and
only
have
access
to
these
hardened
shared
intrinsics
and
anything
else
that
you
have
explicitly
granted
your
program.
B
So
what
lockdown
does
is
it
prepares
the
shared
primordials
or
so
sometimes
called
intrinsics
objects
that
are
like
the
array
and
the
object
and
object
constructors
and
their
prototypes,
and
then
it
goes
on
and
fixes
some
of
the
features
of
the
language
so
that
the
the
programs
that
use
them
can't
interfere
with
each
other,
like
deleting
eliminate
deleting
the
ability
to
to
get
access
to
high
resolution
timers
by
default.
B
They
can
be
granted
back
if
you
understand
the
risk
of
granting
back
timers
and
and
take
other
measures
to
protect
against
that
problem,
but
you
can
also
re.
It
also
removes
unrecognized
methods
in
the
environment
just
in
case,
and
it
freezes
everything
everything
that
will
be
shared.
That
is,
some
of
these
objects
are
subtle,
like
like
the
iterator
prototype
and
the
async
function,
prototype
which
you
can
only
get,
but
you
can
which
anybody
can
get
by
using
javascript
syntax
and
doesn't
necessarily
need
access
to
global
scope.
B
So
we
go
and
find
all
of
those
things
and
harden
them
on
your
behalf,
and
then
we,
then
we
freeze
the
transitive
properties
of
all
these
things,
and
that
makes
the
entire
environment
pro
tamper-proof.
B
Then
lockdown
also
prepares
the
harden
function
and
the
compartment
constructor,
the
hardened
functure.
The
hardened
function
is
for.
You,
though,
is
so
that
what
what
lockdown
does
is
it
creates
this
environment,
where
you
can
defend
yourself
and
to
defend
yourself,
you
need
to
harden
your
own
apis.
B
So
within
a
compartment,
prototype
pollution
attacks
are
not
really
possible
and
then
you
have
the
harden
function.
You
can't
do
things
like
subverting
the
definition
of
nan.
You
can't
redefine
math,
you
can't
munge
the
shared
prototypes.
You
only
get
what
I
gave
you,
and
so,
returning
to
our
concrete
example,
we
could
write.
We
can
write
an
api
that
allows
us
to
run
javascript
queries
on
our
server
with
limited
vulnerability.
Now
there
are,
there
are
things
that
still
can
happen
like
you
can
limit
avail.
B
A
str
an
attacker
could
limit
availability
by
running
an
infinite
loop.
There
are
other
ways
of
getting
around
that
problem,
that
and-
and
that
goes
beyond
hardened
javascript
things
like
metering
the,
so
the
application
would
to
do
this
needs
to
arrange
a
compartment
in
which
to
run
the
queries
and
because
the
compartment
is
going
to
be
shared
with
multiple
parties.
What
we
do
is
we
freeze
that
global
this
right
on
top.
B
B
B
Then,
with
this
arrangement,
the
queries
can't
directly
access
the
database
because
they
don't
have
access
to
a
reference
to
the
database
object.
They
only
have
the
ability
to
look
at
individual
items
from
the
database,
so
they
can't
stage
a
man-in-the-middle
attack
or
exploit
re-entrance
by
polluting
the
shared
array,
prototype
or
any
of
those
kinds
of
things.
B
Any
of
part
of
your
program
can
use
without
asking
you
so
that
this
is
in
contrast
to
the
common
approach
to
creating
sandboxes,
which
relies
on
a
marked
course
boundary
called
a
realm
or
an
even
coarser
boundary
called
the
the
the
inter-process
boundary.
Then
that's
so
the
realms
are
like
iframes
or
what
the
v8
calls
a
vm
context
and
with
those
approaches,
each
tenant
program
gets
their
own
unique
set
of
primordials
like
their
own
array.
Constructor.
B
The
problem
with
this,
though,
that
we
can
overcome
with
hardened
javascript,
is
that
there
ends
up
being
this
identity.
Discontinuity
that
the
array
from
one
realm
is
any
array
from
one
realm
is
not
recognizable
as
an
array
to
another
another
com,
another
realm
and
that
makes
them
sort
of
chemically
incompatible
and,
ultimately,
while
separate
realms,
can
defend
against
explicitly
partitioned
explicitly
partition
programs.
You
might
find
that
the
enemy
is
already
within
the
gate.
So
all
modern
software
is
running
in
this
crowded
house,
regardless
of
whether
they
can
do
so
safely.
B
They
all
have
they're
all
vulnerable
to
their
dependencies.
Their
software
supply
chain-
and
you
know,
a
modern
javascript
program-
consists
of
around
three
percent
novel
code.
The
code
that
you
write
and
the
rest
of
it
is
all
dependencies
and
you
have
to
keep
those
up
to
date
and
every
time
you're
updating
a
dependency.
You
have
this
terrible
bargain.
B
You
have
to
make,
on
the
one
hand,
you're
thinking
well,
if
I
update
my
dependency
that
might
bring
in
a
new
attacker,
but
on
the
other
hand,
if
I
don't,
I
might
be
failing
to
patch
some
security
vulnerability
in
my
system.
There
has
to
be
a
better
way
than
having
to
make
this
choice,
and
our
partners
at
metamask
are
using
hardened
javascript
to
build
a
tool
called
lava
mult
that
does
that
and
it.
B
The
way
it
works
is
that
it
puts
every
third-party
dependency
in
its
own
compartment
and
then
through
static
analysis
decides
whether
each
of
those
compartments
needs
to
have
any
particular
capability
beyond
beyond
the
inert
mathematical
capabilities
of
a
programming
language,
and
to
do
that,
and
then,
if
it
does,
that
it
writes
up
a
policy
which
does
two
things,
one
of
which
it
tells
the
hardened
javascript
layer.
What
to
give
that
program
and
the
other
is
it
tells
you,
the
author
of
that
application?
B
B
Programs
off
of
the
internet
in
in
environment
that
can,
that
is
more
capable.
We
and
members
of
the
agor
pardon
the
gorick
and
members
of
the
cess
community.
The
hardened
javascript
developers
are
pursuing
standardization
of
hard
javascript,
but
you
really
don't
need
to
wait.
We
wrote
a
shim
and
that's
what
we're
using
and
and
moddable,
and
an
embedded
systems
company
created
a
javascript
engine
called
xs
and
it
implements
all
of
these
features.
Natively
and
and
idegoric.
B
We're
using
that
as
well
for
other
purposes
like
snapshotting
and
metering
for
agora,
carbon
javascript
is
the
foundation
that
allows
us
to
run
these
smart
contracts,
determine
deterministically
and
safely.
It's
part
of
this
decentralized
or
distributed
operating
system.
Where
prom
we
can
use
promises
as
proxies
for
remote
objects,
issuing
heavy
rpc
frameworks
and
and
creating
this
much
simpler
and
more
familiar
programming
model
and
having
security
as
well.
B
So
why
hardened
javascript
as
opposed
to
anything
else
for
one,
it's
the
most
popular
programming
language
in
the
world
and
it
gives
us
it
makes
it
possible.
It
gives
those
programmers
the
ability
to
write,
secure
programs
which
is
huge,
but
allow
me
to
digress
for
a
moment
into
my
motivation
for
contributing
to
the
project.
B
I
like
exciting
projects
and
for
me,
an
exciting
project
has
three
noteworthy
traits.
First,
it's
evident.
If
the
project
succeeds,
almost
everything
naturally
comes
to
depend
on
it
and
it
creates
a
world,
that's
new,
it's
bigger,
cooperative
and
safer,
more
accessible
than
the
old
one,
or
the,
and
and
also
that
the
project
creates
an
explosion,
a
cambrian
explosion
of
diversity
and
activity.
B
The
second
trait
is
that
nobody
really
wants
it.
It's
kind
of
exciting
to
have
something
of
value
that
nobody
knows
is
valuable
yet
and
the
most
most
people
really
just
don't
know
about
it,
and
then,
after
that,
you
get
to
the
people
who
know
about
it,
but
dismiss
it
because
it's
unlikely
to
get
transacted
to
get
traction
and
then
there's
also
and
a
lot
of
people
don't
want
it
because
it's
inconvenient
and
it
would
require,
rethinking
and
retooling,
all
of
which
are
fair
reasons
to
not
think
about
a
project.
B
And
my
experiences
with
this
kind
of
thing
are
like
like
in
2006,
I
was
working
on
modules
for
javascript
and
at
the
time
nobody
really
wanted
that
everybody
was
really
happy,
topologically,
sorting
all
of
their
dependencies
and
script
tags
by
hand,
and
that
really
was
sufficient
for
all
the
things
we
were
doing
at
the
time.
B
But
if
you
think
about
it,
the
reason
it
was
sufficient
is
because
that's
all
you
could
do
and
now
with
node
and
npm
and
common
gs,
we
write
a
lot
more
types
of
software
than
we
used
to
and
then
from
that
I
because
of
that
experience,
I
met
our
agorix
chief
scientist
mark
miller,
who's
whispered.
In
my
ear
that
I
really
ought
to
learn
about
promises,
and
then
I
wrote
this
q
promise
library.
B
So
if
you
think
that
getting
javascript
programmers
to
adopt
modules
was
an
uphill
battle
just
like
knowing
that
javascript
module,
like
modules
in
general,
are
solve
problem
in
most
languages
and
everybody
knows
what
they're
supposed
to
do.
You'd
think
it
would
have
been
easier
but
think
about
promises.
B
It
took
a
long
time
to
convince
people
that
promises
were
the
way
that
javascript
should
work
and
now
now
they're
just
part
of
the
language
and
it's-
and
I
think
that
it's
obvious
now
in
hindsight,
that
it
makes
it
easier
to
program
and
then
on
top
and
we
only
breach
the
tip
of
the
iceberg
with
promises.
The
next
step
with
them
is
using
them
as
a
basis
for
communicating
to
third
parties
and
other
workers,
as
proxies
for
objects
and
with
giving
programmers
the
simplicity
of
the
object
of
object,
oriented
programming
for
writing
complex
protocols.
B
So
I
think
you're
going
to
hear
about
hardened
javascript
again
and
the
purpose
again
again
of
hard
javascript
is
to
realize
this
cambrian
increase
in
software
diversity
by
allowing
a
greater
degree
of
cooperation
between
programs.
So,
like
odysseus,
please
sail
forth
from
here
and
listen
to
the
siren
song
and
live
to
tell
the
tale.
B
That's
me
and
I'm
a
software
engineer
at
a
gorick,
and
I
work
on
hardin
javascript
with
an
incredible
team,
and
it's
it's
been
a
pleasure
speaking
here
and
I'm
open
to
questions
at
this
point.
Chris
there's
a
general
question,
which
is
where,
where
should
people
go
to
learn
more
about
this
right
now?
Yeah,
I,
if
you
go
to,
if
you
go
to
my
twitter
stream,
I'd
post.
B
My
the
last
message
I
posted
was
a
link
to
the
slides
for
this
deck,
which
includes
all
of
the
hyperlinks
for
and
and
some
code
examples.
If
you
need
some
clarification
or
an
idea
about
what
that
database
looks
like
and
and
that's
that's
the
best
place
to
start.
There's
we're
on
github.
B
This
hardin
javascript
is
an
open
source
project
best
place
to
look
is
on
github
under
the
endo
jsorg,
the
endo
project
and
the
package
cess,
and
that
gives
you
that
that's
a
good
place
to
start
on
the
documentation
for
hard
javascript
and
there
is
a
link
in
the
deck
for
that
fantastic.
A
B
So
you
can
go
to
chris's
twitter,
which
is
at
chris
kowal,
k-r-s,
k-o-w-a-l
yeah,
and
I'm
I'm
super
looking
forward
to
the
next
presentation
from
our
our
friend
tom
funkutson,
and
he's
going
to
talk
in
much
greater
detail
and
with
about
what
hardened
javascript
is
and
what
how
it's
layered.