►
From YouTube: SES Meeting: Building Membranes in JavaScript
Description
Alex Vincent presents an early draft presentation on JavaScript membranes.
A
So
with
that,
I
would
welcome
interruptions
at
any
point.
I
would
prefer,
of
course,
notes
put
on
the
slides
themselves.
If
you
have
that
capability,
if
someone
could
test
to
make
sure
that
capability
is
working,
please
let
me
know
now,
otherwise,
I'm
just
gonna
ramble
on
and
again
feel
free
to
interrupt
at
any
point,
this
is
not
a
dry
run.
This
is
just
a
walk
through
to
the
best
of
my
ability
of
what
I
expect
to
say.
A
A
A
A
Others
are
public,
but
we
may
not
want
all
such
public
methods
exposed
to
foreign
code.
It's
common
to
define
interfaces
such
as
document
here
to
explicitly
name
what
foreign
code
may
see,
but
the
interface
itself
doesn't
implement
the
restrictions.
It's
just
a
description
of
what
the
program
wants
to
expose
regarding
web
standards.
There
are
standard
interfaces
for
most
document,
object,
model
or
dom
objects,
browsers
use
these
interfaces
to
create
restricted
access
to
these
underlying
objects.
A
A
proxy,
by
contrast,
is
a
special
object
which
emulates
other
objects
in
javascript.
It's
primarily
composed
of
two
parts,
a
shadow
target
and
a
proxy
handler
through
most
of
these
slides
I'll,
follow
the
convention
of
using
the
semicircles
for
proxies
and
full
circles
for
actual
objects.
This
is
standard.
Whenever
people
talk
about
membranes
in
order
to
guarantee
that
a
proxy
obeys
the
rules
of
javascript,
the
proxy
must
store
any
knowledge.
It
has
about
an
object
on
another
object.
A
A
A
One
nice
thing
about
feature
about
proxies
is
that
you
don't
have
to
define
all
the
properties
of
a
proxy
before
the
user
sees
it
at
least,
most
of
the
time
the
proxy
traps
allow
for
defining
properties.
When
you
look
them
up,
so
we
defer
the
work
necessary
for
filling
a
proxy's
properties
until
they're
needed
in
a
normal
proxy.
You
would
define
the
shadow
target's
property
to
be
the
same
as
the
actual
target's
property.
A
However,
membranes
prefer
to
define
these
shadow
properties
as
pointing
to
other
proxies,
and
I
will
explain
why
in
a
little
bit,
finally,
javascript
proxies
may
be
revoked
at
any
time.
This
disconnects
the
proxy
from
the
shadow
target
and
renders
the
proxy
inert
any
attempt
to
use
the
proxy
after
it
has
been
revoked,
will
throw
an
error.
A
A
A
A
B
One
of
the
things
that
I've
found
is
that
people
like
colors,
like
blue
and
yellow
as
the
names
much
more
than
they
like
terms,
wet
and
dry,
wet
and
dry
for
me,
have
have
a
wonderful
intuition,
but
especially
as
you're
going
to
get
I've
seen
your
size
before.
Is
he
going
to
get
into
multi-way
things
where
you
have
additional
things
besides
wet
and
dry,
having
them
simply
be
other
colors
at
that
point
really
makes
compellingly
more
sense
than
introducing
concepts
like
them.
B
A
Fair
enough,
let's
see,
we
have
a
membrane
and
two
object
graphs
which,
for
those
purposes
of
this
convention
I'm
calling
wet
and
dry
suppose
we
have
a
dry
proxy
to
the
document
object.
Already.
There
are
several
relationships
defined.
We
have
two
proxy
handlers
and
generally
two
weak
maps
we'll
come
back
to
one
of
the
exceptions
to
that
later
on,
one
weak
map
is
specifically
for
keys
in
the
wet
object
graph
or
trusted
object,
graph
pointing
to
values
in
the
dry
object,
graph
or
untrusted.
A
The
other
weak
map
defines
the
reverse
operation
keys
in
the
dry,
object,
graph
point
and
key
and
values
in
the
wet
object
graph
to
get
the
body
property
of
the
dry
document
proxy.
The
membrane
does
several
things.
First,
the
dry
proxy
handler
will
get
the
request
and
look
up
the
document.
The
document
object
in
the
dry
week
map
based
on
the
shadow
target.
A
A
It
creates
a
proxy
from
the
shadow
target
and
the
dry
proxy
handler
in
the
dry
week
map
it
creates.
It
sets
the
shadow
target
as
a
key
pointing
to
the
body
object,
and
then
it
does
the
same
using
the
proxy
as
a
key,
also
pointing
to
the
body
object,
then,
in
the
weak
wet
map
it
sets
the
body
object
as
a
key
pointing
to
the
proxy.
A
A
Where
was
I?
Finally,
the
body?
The
dry
proxy
handler
returns
the
new
body
proxy
collar
to
the
collar?
I
got
to
work
on
this
guys
and
on
the
dry
object
graph.
It
looks
like
the
document
proxy
has
a
property
named
body
pointing
to
the
body
proxy.
I
apologize
for
the
timing
again
still
pretty
rough
well.
What
about
looking
at
the
owner
document
of
the
body
element?
Well,
that's
much
easier
because
there's
already
a
proxy
for
the
document,
the
dry
proxy
handler
gets
the
request
and
looks
up.
A
The
body
object
in
the
dry
week
map
based
on
the
shadow
target,
the
javascript
engine
grabs.
The
document
object
for
the
return
trip
and
the
membrane
asks
the
wet
weak
map.
If
there
is
a
proxy
for
that
document,
object.
What
weak
map
returns
that
proxy
and
after
ensuring
the
document
proxy
is
defined
as
the
owner
document
property
of
the
body
proxies
target,
the
drive
proxy
handler
returns,
the
document
proxy
and
the
work
is
done.
A
A
So,
let's
talk
a
little
bit
about
object,
graphs.
This
is
yet
another
building
block
piece
towards
membranes
in
general
from
graph
theory.
I'm
sorry,
I'm
not
going
to
read
from
the
side.
We
have
an
object
graph,
which
is
a
collection
of
objects
called
nodes
and
the
relationships
between
them,
which
we
call
edges
in
a
browser.
The
html
elements
combine
to
form
a
single
object
graph,
and
here
we
have
the
edges
drawn
as
property
names
from
one
node
to
another.
A
It's
worth
pointing
out
that
where
these
nodes
appear
on
the
graph
has
zero
relationship
to
the
expense
of
going
from
one
node
to
another.
Aside
from
the
obvious
that,
from
to
get
from
the
html
amount
to
the
title
element,
you
have
to
go
through
the
head
element.
First,
I
could
place
the
title
node
on
the
far
right
side
of
this
slide
and
it
wouldn't
change
the
graph
at
all
for
the
purpose
of
membranes.
We
can
mostly
ignore
the
time.
Complexity.
A
A
Now
I
show
the
connections
of
these
proxies
to
their
underlying
objects.
This
brings
us
to
membranes.
A
membrane
is
the
coordinator
between
object,
graphs.
It
establishes
rules
for
how
object
graphs
talk
to
each
other
via
specialized
proxy
handlers
which
manage
proxies
within
individual
object,
graphs.
A
Each
object
graph
handler
is
responsible
for
creating
new
proxy
objects
as
necessary.
For
instance,
I
may
have
an
internal
object
graph
with
thousands
of
nodes
and
edges,
but
my
public
object
graph
only
has
one
node
in
it.
Initially,
this
is
simply
leveraging
the
initialized
on-demand
traits
of
proxies.
A
A
A
A
A
A
A
A
So
why
are
membranes
important
first
there's
security
against
untrusted
access.
This
is
simply
saying
that
access
through
a
membrane
proxy
to
its
original
target
is
restricted
in
very
specific
ways,
which
the
membrane
creator
must
specify
recall
that
a
proxy
only
emulates
an
object.
This
means
that
the
proxies
handler
determines
what
properties
the
proxy
exposes.
A
Excuse
me
suppose
alice
provides
a
car
object
to
bob
where
bob
wants
to
install
a
9-volt
battery,
but
alice
doesn't
trust
bob,
certainly
not
to
pop.
The
hood.
Alice
wants
her
car's
battery
to
be
a
private
or
hidden
property
sure
she
could
write
a
center
function
to
validate
the
argument,
but
she
doesn't
even
want
bob
to
know,
there's
a
place
to
put
a
battery.
A
A
A
Here's
another
example
of
why
membranes
can
be
interesting,
and
admittedly,
this
one
is
more
theoretical
than
known
at
this
time.
If
there's
a
shared
car
object
and
alice
wants
to
set
a
windshield,
maybe
the
memory
will
allow
that
if
bob
wants
to
set
a
set
of
windshield
wipers
on
the
car,
maybe
the
membrane
will
allow
that
too.
A
So
what
do
we
expect
from
a
membrane?
First
of
all,
perfect,
mirroring
primitive
values
get
passed
through,
at
least
by
default.
Non-Primitive
values,
objects,
functions,
arrays,
etc.
They
are
wrapped
in
proxies
by
default
and
through
the
defined
api
constraints.
If
there
are
any
property,
lookups
and
functions
work
just
as
if
we
were
under
interacting
with
the
underlying
objects.
A
A
When
you
consider
what
objects
are
in
an
object-oriented
language,
there
are
a
few
simple
distortions
we
can
define.
We
already
mentioned
heightening
properties
in
javascript.
What
we
would
do
is
two-fold.
First,
we
would
prevent
the
property
name
from
showing
up
in
the
list
of
the
object's
own
keys.
Second,
any
attempt
to
look
up
that
property
returns
undefined.
A
Another
common
distortion
would
be
storing
unknown,
prop
properties
locally.
On
the
proxy
perfect,
mirroring
means
new
properties
would
pass
through
to
the
underlying
object
properly
wrapped.
Of
course,
this
distortion
means
the
new
property
doesn't
pass
through.
But
whenever
you
look
up,
look
it
up
on
the
proxy.
You
still
get
that
property.
A
This
distortion
means
manipulating
a
few
distinct
traps,
such
as
own
keys,
get
on
property,
descriptor,
define
property.
Mozilla
developer
network
calls
these
expandos
the
properties.
A
related
distortion
is
making
deletions
of
properties
local.
That
simply
means,
if
you
execute
a
delete
operation
on
proxy,
that
delete
doesn't
go
to
the
underlying
object.
Gentlemen,
I
have
no
idea
what
time
it
is.
I
don't
know
if
I'm
getting
close
to
the
end
of
the
allotted
time
for
this
meeting
you're
doing
fine,
okay,
yeah.
A
A
A
A
So
there
are
membranes
in
use
right
now,
although
most
people
don't
realize
this,
which
is
sort
of
the
point
of
having
membranes
in
the
first
place,
one
very
popular
membrane
implementation
is
in
mozilla
firefox.
The
web
browser
firefox
calls
these
cross
compartment
wrappers.
They
provide
a
layer
of
abstraction
and
security
between
the
browser's
document,
object,
model
or
dom,
and
the
web's
vast
multitude
of
javascript
files,
the
wrappers,
are
the
membrane
proxies.
A
A
A
Graph,
so
let's
talk
a
bit
about
the
history
behind
membranes
and
their
concepts.
We
have
dr
mark
miller
who's
actually
on
this
call,
as
everyone
knows,
and
dr
tom
van
cutsem,
the
two
of
them
work
together
to
invent
the
concept
of
a
membrane
or
to
evolve
it
from
pre-existing
concepts
that
I
do
not
know
about
mark
I
was
hoping
we
could
get
photos
of
you
and
tom.
We
can
talk
about
that
offline
or
we
can
drop
this
slide
if
you're
really
uncomfortable
about
that.
B
A
A
A
A
Only
the
membrane
proxies,
which
the
membrane
specifically
creates,
may
breach
this
cell
wall.
If
anything
else
can
that's
a
bug,
the
idea
is
that
each
object
on
the
wet
side
may
have
a
dry
proxy
and
each
object
on
the
dry
side
may
have
a
wet
proxy
beyond
that,
nothing
on
the
dry
object
graph
knows
anything
about
the
wet
object
graph,
including
its
existence,
and
vice
versa.
A
A
A
Well,
if
an
object
graph
lives
in
a
plane,
then
two
object:
graphs
can
form
two
parallel
planes.
The
fact
they're
parallel
means
they
can
never
intersect.
So
again,
objects
in
one
graph
cannot
touch
objects
in
another.
Keeping.
The
idea
of
full
circles
for
objects
works,
but
not
semi-circles
for
proxies,
so
I
can
replace
the
semicircle
with
a
hemisphere
for
a
proxy
with
the
flat
side
facing
the
underlying
object.
Similarly,
I
replaced
the
circle
for
an
object
with
a
sphere.
Edges
remain
lines
in
each
object:
grass
planes.
A
A
A
I
think
it's
pretty
easy
to
see
that
the
cell
membrane
model
and
this
geometric
model
describe
the
same
basic
concepts.
What
works
in
the
cell
model
works
in
the
geometric
model.
Obviously,
the
concept
of
being
inside
a
cell
converts
to
being
inscribed
in
a
plane
but
being
outside
a
cell
just
means
you're
in
another
plane.
A
A
Initially,
the
secure
ecmascript
community
called
this
a
multi-sided
membrane
to
distinguish
it
from
the
two-sided
membrane,
where
there
was
a
wet
side
and
the
dry
side.
However,
a
later
discussion
led,
a
parallel
group
called
fry
am
to
propose
that
the
connections
between
object
graphs
is
a
type
of
hypergraph.
A
A
Even
worse,
let's
say
that
bob
already
has
his
own
view
through
the
membrane
of
this
dom
node.
Then,
when
alice
sends
him
the
message
with
her
proxy
the
proxy
he
receives.
As
an
argument,
analysis
message
would
also
point
to
this
dom
node,
but
it
would
be
a
separate
proxy
altogether,
two
different
ways
of
looking
at
the
same
object.
A
A
So,
as
you
scale
up
the
number
of
membranes,
the
number
of
of
I'm
sorry,
as
you
scale
up
the
number
of
object,
graphs,
the
number
of
membranes
explodes
at
a
square
rate
and
keep
in
mind,
you
have
two
weak
maps
and
two
proxy
handlers
per
two-sided
membrane,
keeping
them
all.
Synchronized
is
a
headache
that
no
one
wants
to
go
into
for
a
hypergraph
membrane.
Adding
an
extra
graph
actually
is
constant
time,
constant
space
consumed
for
it.
Of
course,
you
have
to
have
more
space
for
the
individual
proxies,
but
you
create
them
on
demand.
A
So
that's
really
not
a
problem.
It's
slightly
more
complex
to
implement
membranes
are
very
complex.
Beasts
to
implement
anyway,
membranes
require
a
bit
more
bookkeeping,
though,
for
instance,
when
you
have
a
function
you
have
to
pat
you
have
to
wrap
the
function.
You
have
to
wrap
all
the
arguments,
including
this
argument,
pass
it
through
to
the
membrane
run.
It
run
it
in
the
native
graph,
as
proxies
I'm
sorry
as
underlying
objects,
and
then
you
wrap
the
return
value
so
that
it
fits
in
the
caller's
object
graph,
probably
as
a
proxy
there's.
A
Also,
how
do
you
store
the
rules
of
the
proxy?
What
kind
of
management
manager
for
all
this
data
is
there?
It's
not
just
a
vanilla
object,
although
it
could
be,
it
just
gets
more
and
more
complicated
and
you
kind
of
need
something
new
and
that's
where
my
es
membrane
library
comes
in.
I
spun
it
off
of
a
dead
project
died
a
couple
years
ago,
specifically
to
focus
on
membranes.
A
So
proxy
mapping
objects
they're
the
real
secret
sauce.
Here
they
do
all
the
work
of
managing
the
data.
You
can
think
of
them
as
json
objects
in
a
sense,
except
that
they
have
functions.
Okay,
that's
not
a
really
good
analogy,
but
their
data,
primarily
with
the
exception
of
also
having
revoked
methods
that
proxy.create
revocable,
provides
to
us.
A
A
I'm
sorry
the
wet
object
data,
the
original
object,
also,
the
dry
proxy
data,
including
the
revoke
function,
the
shadow
target
and
other
metadata
on
how
that
proxy
should
operate
and
that
results
in
a
proxy
for
the
pr
for
the
dry
graph
and
the
dry
proxy
handler
uses
its
shadow
to
point
through
the
same
through
the
weak
map
to
the
same
proxy
mapping.
So,
instead
of
two
week
maps
now
it's
down
to
one
and
a
secondary
key
for
what
object,
what
object
graph
you're,
pointing
to.
A
This
allows
this
proxy
mapping
allows
me
to
point
to
multiple
graphs
and
scale
up
pretty
easily.
As
I
mentioned,
we
have
wet
and
dry.
Damp
is
a
third
name
that
I
came
up
with
for
a
third
object
graph
and
steamy
is
the
fourth
one
I
came
up
with
again.
Those
are
just
names:
they
have
no
meaning
beyond
the
theory.
A
A
A
A
That
doesn't
say
that
it's
easy
to
get
right,
so
there's
a
little
bit
of
work
that
is
still
to
be
done
at
the
at
the
unite.
Thirty
thousand
foot
level
for
es
membrane.
I
brought
up
error
stack
traces
in
the
original
talk,
but
it's
looking
like
tc39
is
leaning
against
ever
allowing
that
to
formally
be
permitted.
A
A
B
A
B
A
A
It
turned
out
that
the
proxy
handler
code
got
really
long,
really
complicated
and
integrates
a
whole
bunch
of
different
functionalities
into
the
same
single
file.
That
was
probably
a
tactical,
I'm
sorry,
a
strategic
mistake:
I'm
trying
to
break
that
out
into
smaller
components
that
are
actually
easier
for
plugging
into
each
other
and
then
there's
properly
converting
the
es6
modules,
which
I
am
a
little
late
to
the
party
on,
but
it
would
also
bring
some
benefits,
there's
also
integrating
with
realms
and
frozen
realms.
Now
these
are
new
proposals
that
have
not
yet
landed
in
javascript
engines.
A
These
tc39
proposals
are
about
providing
copies
of
your
top
level:
globals
object,
function,
string
date,
number,
boolean,
etc
that
users
can
manipulate
without
impacting
the
main
scripts
global.
So
you
have
your
own
completely
separate
set
of
these
globals
that
if
you
change
them,
you
won't
hurt
the
original
code
in
doing
so,
there's
also
standard
distortions
for
collections.
A
So
that
needs
some
special
handling
to
behave.
The
way
we
expect
them
to
less
complicated
but
still
relevant
maps
and
sets
might
face
the
same
kind
of
problem
and
then
completely
revisiting
how
we
configure
a
membrane.
Since
the
last
time
I
gave
this
talk,
I've
learned
a
lot
through
college,
there's
a
possibility.