►
From YouTube: Agoric + Protocol Labs // Part 2 - Object-capability Programming in Javascript - Mark Miller
Description
Part 2: Object-capability Programming in JavaScript
At first blush, JavaScript might seem a strange candidate for a secure programming language. But initial impressions can be deceiving. We show how JavaScript can be used as a secure, object-capability language. With SES, our secure JavaScript runtime, developers can write robust and reliable smart contracts.
A
A
Throughout
the
talk,
I'm
only
going
to
be
making
use
of
two
main
abstraction
mechanisms
in
JavaScript
the
function
and
the
record
over
here
we
have
a
function
called
make
counter
on
the
outside
and
every
time
it's
called.
It
creates
a
new
record
with
an
inker
and
dekker
method
and
a
new
count
variable,
which
is
effectively
the
instance
variable
of
this
object.
A
The
anchor
and
dekker
are
shown
on
the
surface
because
they're
visible
outside
the
object.
The
count
variable
is
so
shown
inside
because
it's
encapsulated
only
the
inker
and
Decker
method
can
get
to
it.
Every
time
we
call
make
counter.
We
get
a
distinct
instance,
and
each
of
these
instances
is
isolated
from
the
others.
A
What
can
we
do
with
this?
Well,
for
example,
maybe
we
want
to
keep
track
of
the
number
of
people
inside
a
room
by
having
an
entry
guard
count
up
when
people
are
entering
the
room
and
an
exit
guard
count
down
when
people
exit
the
room.
So
we
can
give
the
entry
guard
access
to
the
anchor
function
and
the
exit
guard
access
to
the
Decker
function,
and
the
result
is
that
the
entry
guard
can
only
count
up.
A
The
exit
guard
can
only
count
down,
so
this
gets
at
the
core
idea
of
object
capabilities,
which
is
a
conventional
object.
Reference
familiar
from
object,
programming
is
a
permission.
If
object,
Bob
does
not
have
a
reference
to
object.
Carol
then
Bob
cannot
invoke.
Carol
cannot
provoke
whatever
behavior
Carol
would
have.
If
Alice
has
a
reference
to
Bob
and
Alice
invokes
Bob
passing
Carol
as
an
argument,
then
Alice
has
both
used
her
permission
to
invoke
Bob
and
given
Bob
permission
to
invoke
Carol.
So
this
is
all
familiar
from
memory.
Safe
object,
languages.
A
A
It
gives
us
a
very
natural
way
to
express
the
principle
of
least
Authority
in
which
an
object
is
only
given
that
permission.
That
it
needs
to
do
its
legitimate
job,
such
as
giving
the
entry
guard
only
the
ability
to
increment
the
counter
and
by
giving
objects
very
narrow,
Authority.
You
deny
them
most
of
the
opportunities
for
things
to
go
wrong
for
them
to
do
damage.
If
there's
an
exploitable
bug
the
fact
that
JavaScript
can
be
used
in
this
robust
and
secure
manner
is
no
accident.
A
I
joined
the
Xmas
crypt
committee
in
2007,
when
JavaScript
was
really
a
tremendously
messy
language,
and
we
got
all
of
these
elements
added
to
JavaScript,
beginning
with
JavaScript,
strict
mode
and
object
dot
freeze
in
Ekman
script
5.
We
got
all
of
these
things
added
in
order
to
enable
JavaScript
B
to
be
used
more
reliably
and
more
securely
javascript.
The
language
has
no
IO.
A
A
It's
also
now
very,
very
prominent
on
single
machine
servers.
It's
also
very
prominent,
but
not
well
known,
to
be
prominent
in
embedded
devices.
Probably
some
of
the
devices
in
your
house
are
actually
running
JavaScript
and,
of
course,
now
we're
running
JavaScript
on
blockchain
and
what
we're
advancing
is
secure,
Eckman
script.
Is
this
secure
runtime
for
enforcing
the
security
properties
needed
to
turn
JavaScript
into
an
object
capability
language?
A
There
is
now
a
standards
organization,
TC
53
for
standardizing
the
JavaScript
for
embedded
devices
and
that
standardized
standards
organization
is
explicitly
standardizing.
Lon
ses,
secure,
ACMA
script
as
the
standard
javascript
for
embedded
devices.
The
main
embedded
javascript
is
the
XS
engine
from
moddable
and
that
one
they
already
have
a
configuration
out-of-the-box,
that's
directly,
an
SES
engine.
A
Of
course
a
goreck
is
supporting
javascript
on
blockchain
and
we've
been
working
with
meta
mask
meta
mask
also
on
the
browser
is
a
platform
that
people
use
to
write
user
interfaces
for
interacting
with
distributed
apps
distributed
apps
that
run
on
block
chains
with
to
interact
with
smart
contracts
and
they've
been
using
browserify
as
their
module
system
for
packaging
modules
to
run
on
the
browser.
They
are
now
switching
from
browserify
to
Sesa
phi
they've
built
Sesa
Phi,
which
is
a
version
of
browser
5
that
has
cess
built-in.
A
So
why
is
it
that
all
of
these
different
major
players
are
putting
so
much
effort
into
switching
to
secure
etna
Script?
These
are
the
packages
that
make
up
a
meta
mask
bundle
as
run
under
JavaScript
today.
Each
of
these
packages,
if
it
misbehaves,
can
completely
destroy
the
integrity
of
what
it's
running
in
and
when
meta
mask
is
being
used
to
manipulate
financial
assets
on
block
chains.
Then,
if
meta
mask
is
corrupted
by
one
of
these
packages,
then
it
can
not
only
destroy
the
integrity
of
your
user
interface.
A
Okay,
so
the
truth,
so
so
I'm
actually
very
impressed
at
how
accurate
those
answers
were.
Npm
estimates
that,
for
the
typical
JavaScript
application,
the
answer
is
three
percent,
which
means
97%
of
the
code
that
you
link
together
to
create
an
application,
is
third-party
code
that
you
have
little
reason
to
be
had
to
have
confidence
in
and
in
JavaScript
as
it's
run
today,
every
one
of
those
packages
is
given
all
of
your
authority
and
can
abuse
anything
that
the
application
itself
was
given
to
manipulate.
A
A
All
of
these
others
are
third-party
packages
that
are
linked
in,
but
the
green
ones
are
those
that,
after
static
analysis
about
what
it
apparently
uses
is
then
run
under
SES
in
such
a
way
as
to
be
given
only
the
authority
that
it
apparently
uses
and
therefore,
even
if
it's
malicious,
its
ability
to
do
damage
is
very
little.
The
red,
of
course,
are
the
real
hotspots,
the
things
that
our
that
need
a
deeper
security
review.
So
why
are
they
red?
Let's
mouse
over
that
one?
A
And
we
see
that
that
one's
red,
because
it
directly
accesses
the
network,
it
uses
xml
httprequest
as
a
global
variable.
Therefore,
in
order
to
run
this
application,
you
have
to
run
that
module
in
an
environment
in
which
there
is
such
a
global
variable.
That
seems
to
be
a
global
exit,
xml
httprequest
object
and
any
security
review
should
start
with
these
hotspots
should
focus
the
attention
on
these
hotspots.
First.
A
So
how
is
it
that
we
got
from
this
tremendously
messy
language
JavaScript,
as
it
was
in
2007
to
the
ability
to
use
JavaScript
securely
in
this
way?
Well,
our
approach
has
the
slogan:
don't
add
security,
remove
insecurity,
so
Eknath
script
has
some
really
terrible
features
that
make
secure
programming
impossible.
So
our
first
step
was
to
define
Ekman
script,
strict
mode,
which
we
got
into
Eknath
script
5,
and
that
leaves
out
most
of
those
problematic
features
and
enforces
that
you
stay
within
the
strict
subset.
So
we
can
take
that
off
the
table.
A
Atma
scripts
strict
mode,
still
has
some
severe
problems
that
prevent
it
from
being
used
as
a
secure
language,
in
particular,
any
code
linked
into
a
can
reach
in
to
object,
dot,
prototype,
dot,
push
and
replace
the
push
method.
Sorry,
arrayed
that
prototype
dot,
push
and
repair
replace
the
array,
push
method
with
some
malicious
push
method
that
all
the
other
code
inside.
That
system
is
now
misled
into
using
also
JavaScript,
as
it's
run
today.
A
So
these
are
the
problematic
features
that
we
that
we
need
to
take
off
the
table.
We
need
to
create
a
mechanism
to
enforce
the
absence
of
these
features
and
instead
program
in
a
Java
Script
in
which
those
miss
features
are
repaired.
So
that
is
secure.
Echo
script,
the
good
news
is,
we
had
to
take
very
little
off
the
table
in
order
to
define
secure
echo
script.
A
Secure
ECMO
script
is
essentially
JavaScript
the
experience
going
back
to
the
kaha
project
at
Google.
From
the
you
know,
earlier
the
what
2007
timeframe
we
found
that
a
tremendous
amount
of
old
legacy
code
runs
under
SES
and
today,
with
Salesforce,
with
meta
mask
with
a
goreck.
We're
finding
that
as
well
that
that
a
tremendous
amount
of
old
code
will
run
under
SES
and
therefore
we
can
use
SES
to
bring
these
security
properties.
A
However,
javascript
is
still
a
messy
language
is
still
a
language
that,
if
you
use
the
whole
language,
it
contains
many
features
that
are
hard
to
reason
about
double
equals
is
infamous
for
having
crazy
coercion
rules.
So
what
we've
done
for
our
own
sanity
is
defined.
A
disciplined
subset
called
Jessie.
That
only
has
the
parts
of
JavaScript
that
we
know
we
can
reliably
and
all
the
code
you're
going
to
see
in
this
talk
is
in
the
Jessie
subset
and
most
of
the
code
we
write
at
agaric
is
in
the
Jessie
subset.
A
Salesforce
has
what
they
call
the
lightning
platform,
and
these
the
various
applications
contributed
by
third
parties
that
you
can
select
to
create
a
Salesforce
user
interface
when
you
go
to
they're,
essentially
App
Store
and
pick
the
various
apps
and
compose
them.
Those
are
all
running
in
SES
and
the
fact
that
the
lightning
platform
is
enforcing
that
they
run
in
SES
means
that
the
lightning
platform
itself
is
largely
protected
from
their
misbehavior.
A
And
when
you
compose
multiple
of
these
apps,
together
into
one
sales
for
use
user
interface,
those
apps
are
largely
protected
from
each
other,
so
that
it's
direct
support
for
mutual
suspicion
and
as
a
mark
of
how
compatible
SES
is
a
lot
of
the
people.
Writing
the
Salesforce
apps
to
a
first
approximation,
just
think
of
what
they're
writing
in
as
plain
old
JavaScript
and
it
works,
and
that
once
again
is
also
reflected
in
the
experience
we
had
at
Google
with
kaha.
C
Zooming
sandboxing
of
all
of
the
actual
code,
there
are
some
resource
expenditures
that
this
might
still
permit.
I'm.
Sorry,
there
might
be
resource
expenditures
that
this
might
permit,
so
you
might
be
sunning
code
that
actually
spends
CPU,
and
so
that
might
still
be
an
attack,
vector
I,
wonder
if
you
have
ways
of
statically
detecting
or
these
hints
or
have
an
even
stricter
subset
that
takes
that
away.
So.
A
Let's
divide
blockchain
use
from
other
hosting
environments,
let's
deal
with
the
other
hosting
environments.
First,
there
is
no
protection
against
denial
of
service
by
writing.
An
infinite
loop.
For
example.
Any
of
these
Salesforce
apps
under
the
lightning
platform
when
run,
might
just
go
into
an
infinite
loop
and
hang
the
page
now.
A
The
interesting
thing
is
there
is
very
little
benefit
to
the
attacker
of
writing
such
an
app
and
an
app
that
does
that,
when
incorporated
into
a
page
is
going
to
get
unlisted
and
people
are
just
going
to
stop
using
it
so
for
outside
of
the
blockchain.
The
main
thing
is
that
there's
little
to
be
gained
by
wedging
the
application
you're
incorporated
in
and
there's
a
quick
iteration
where
anything
that
does
that
just
stops
being
used,
because
it's
easy
to
detect
it's
an
attack
that
when
it
happens,
there's
no
mystery.
A
What's
happening,
you're
wedged
now
with
blockchain,
we
we're
planning
to
do
the
same
thing
that
everybody
else
does
on
blockchain,
which
is
essentially
a
gas
model,
a
metered
gas
model
because
of
the
the
way
in
which
we
want
to
incorporate
a
goreck
market-based
resource
allocation
concepts
into
resource
allocation.
We've
got
some
additional
aberration
of
that,
but
essentially
what
the
gas
model
does
is
an
infinite
loop.
Just
starves
that
turn
once
the
turn
is
starved
in
the
blockchain
context.
You
have
everything's
transactional,
you
abort
the
turn
as
a
whole
and
then
it's
as
if
nothing
happened.
A
B
So
it
seems
like
there
is
a
range
of
approaches
to
this
problem
from
something
like
CloudFlare
workers,
where
they're
just
using
v8
isolation
down
to
something
like
star
lark,
which
is
like
super
crippled
Python,
and
it
seems
like
a
lot
of
these
approaches,
have
been
kind
of
dialed
in
for
very
specific
applications,
whereas
this
one
is
trying
to
solve
both
this,
like
in
browser
consumer
application
kind
of
tasks
as
well
as
it
may
be.
What
seems
like
a
different
domain
with
these
financial
applications?
A
So
CloudFlare
is
the
one
that
I'm
familiar
with
Kenton
Varda
at
CloudFlare
is
very
familiar
with.
Our
work
is
very
much
influenced
by
the
object
capability
approach
to
things
and
with
regard
to
the
overall
ambitions
of
cloud
Furler
CloudFlare
workers,
where
one
of
these
things
running
in
loops
should
not
prevent
progress
on
the
other
ones.
For
that
situation,
having
these
things
essentially
run
as
separate
threads
so
that
one
getting
wedge
doesn't
stop.
The
other
was
a
fine
way
to
run
CloudFlare
workers
I
think
that
this,
in
addition
allows
a
much
lighter
weight.
A
Multi-Tenancy
in
their
terminology,
SES
enables
featherweight
compartments
where
each
unit
of
isolation
is
just
characterized
by
creating
a
few
objects
rather
than
an
entire
v8
isolate.
So
we
can
create
much
finer
grain
units
of
isolation,
but
where
you're
not
but
those
finer
grain
units
don't
provide
concurrency
isolation,
the
CloudFlare
workers,
with
their
isolates,
that's
really
the
smallest
practical
unit,
starting
with
JavaScript
for
doing
concurrency
isolation.
B
A
Everything
that
I'm
showing
is
motivated
by
explaining
the
Agora
platform.
But
you
know
the
Salesforce
lightning
platform
builds
on
the
technology
that
we
constructed
together
and
the
Lightning
platform
itself
is
not
part
of
the
Agora
platform,
so
that
sir,
and
likewise
we're
collaborating
with
cosmos
on
creating
the
IBC.
The
intra
block
train
protocol
cosmos
has
many
other
plans
for
the
entire
block
train
protocol
that
are
not
part
of
the
Agora
stack
so
collaborating
with
things
relevant
to
many
other
players,
but
all
of
which
are
relevant
to
the
stack,
we're
building
and.
A
Yes,
one
of
the
things
that's
very
fortunate
is
that
wasm,
the
web
assembly
is
becoming
a
standardized
virtual
machine
for
new
block
chains
and
aetherium,
which
is
the
main
entrenched
case
of
a
different
virtual
machine,
is
putting
a
lot
of
effort
into
switching
from
evm
to
Azzam
the
excess
javascript
engine
that
I
mentioned
from
audible.
That's
that's
used
for
embedded,
that's
actually
the
engine
we're
planning
to
run
on
blockchain
anyway,
and
that
one
already
has
wasm
as
a
first-class
target,
so
that
one
is
an
interpreter,
not
a
JIT
good
luck,
running
jets
on
one
wasm.
A
That
will
never
happen,
but
excess
is
a
straightforward
interpreter
that
compiles
to
wasm
and
therefore
we
can
run
our
java
scripts
on
top
of
any
blockchain
that
ones
wasm
and
we
plan
to
we.
We
have.
We
have
put
in
a
significant
amount
of
effort
into
running
as
a
pair
of
chain
on
top
polka-dot
platform,
and
we
plan
to
get
back
to
that.
C
A
Once
we
have
metering
in
and
working,
we
plan
to
do
it
at
a
level
of
abstraction
such
that
the
metering
mechanism
is
not
specific
to
blockchain,
where
any
other
platform
running
our
software,
if
they're
interested
in
running
in
a
metered
fashion
will
be
able
to
do
so.
In
particular,
we've
already
talked
to
moddable
about
where
you
would
instrument
in
the
XS
interpreter
in
order
to
do
things
like
metering.
A
B
A
Yeah,
the
most
radical
thing
that
that
shocks,
many
JavaScript,
programmers
that
we've
removed
from
SES
to
make
jesse
is
this
the
this
keyword
in
javascript
and
as
a
result
of
removing
this,
we
all
class,
don't
make
sense.
The
prototype
inheritance
pattern
for
polymorphism
doesn't
make
sense.
The
objects
is
closure
pattern,
which
is
what
you
saw
with
the
counter
example.
That's
what
makes
sense
so
it
leads
to
a
very
different
style
of
use.
That's
the
most
radical
change.
There's
lots
and
lots
of
particular
things
that
you're
just
better
off
without
double
equal
versus
triple
equal.
A
We
prohibit
the
use
of
switch
where
you
can
fall
through
from
one
case
to
another,
and
we
have
linting
rules
that
largely
enforce
that
you
stay
within
the
Jessie
subset.
The
Jessie
subset
is
advisory.
If
you
leave
the
Jessie
subset
you're
still
in
SES,
the
object
capability
rules
are
imposed
on
you,
we're
working
with
some
formal
methods,
people
towards
formal
specification
and
verification,
and
the
only
language
that
we
imagine
applying
these
formal
tools
to
is
Jessie
where
the
Jessie
code
coexists
with
SES
code
and
the
formal
methods
tools
have
to
make
that
assumption.